WEEK 1: Documentation

Introduction: p.6
-​ In the first chapter, clearly state what the purpose of the study is and explain the study's
significance. The significance is addressed by discussing how the study adds to the
theoretical body of knowledge in the field and the study's practical significance for
communication professionals in the field being examined. Researchers also must explain
how their research makes an original contribution to the body of knowledge in their
discipline. They also should address the significance of the study for mass
communication education. It is especially critical that this chapter be well developed.
Without a clearly defined purpose and strong theoretical grounding, the thesis or
research is fundamentally flawed from the outset.

-​ Introduction introductory statement about the study

-​ Presents a general statement about the study (can be an issue or claim)
presents support about the general statement (organization or
beneficiaries can be introduce also)
-​ Last paragraph contains either the aims or problems that the study
would want to achieve or solve. p.7

//Example of Introduction: Generally, it is essential to have information in a convenient way

and by that it accelerates the productivity of everyone without wasting time
so much, especially if the people are not familiar in some places and
offices inside the City Hall. Technology is the key to make the society
become more productive and efficient at the same time. So that, the
proponents developed a system for Quezon City Hall to help the workers
and citizens to align with the fast-growing city and to promote quality of
service and avoid waste of time finding the specific locations and
requirements.// p.9

Background of the Study: p.10

-​ The background study for a thesis includes a review of the area being researched,
current information surrounding the issue, previous studies on the issue, and relevant
history on the issue. Ideally, the study should effectively set forth the history and
background information on your thesis problem.

-​ Describes the problems to be investigated

-​ Contains a general problem written in the form of a statement followed
by the specific questions or sub- problems
-​ Includes both the general and specific objectives (must be parallel to
your SOP)
-​ Time and Place of the Study •includes the period when the study was
conducted starting from the preparation of outline, data gathering
(preliminary interview & RRL), conduct of survey to writing of the
Manuscript. p.13
//Example of Background of the Study: To design a system that gives accurate information to
users inside the City Hall Compound.

-​ To design a system that can help the users know a specific location inside the
compound.
-​ To design a system that shows the map of the whole vicinity of Quezon City Hall.
-​ To design a user–friendly system for all types of users.
-​ To develop a system that is technically, operationally and economically feasible
for implementation. // p.14

Scope and Delimitation of the Study:

-​ Describes the extent of the study actual place where the study will
only be conducted
-​ Duration of the conduct of the study inclusions of the study (only
specific aspect of the study or topic) limit of the number of
respondents
-​ Area limit (if applicable). P.15

//Example of Scope:
-​ The system has a two user level accounts such as administrator and the visitor.
-​ The administrator can add and update the events, mapping process and the user of
each terminal can control to access the Kiosk machine.
-​ The system can print information in every specific transaction inside the Quezon City
Hall.
-​ The system can display the vicinity map of Quezon City Hall for the mapping and
providing ways where the user will go.// p.16

//Example of Delimitation:
-​ The system does not include mobile application for the navigation and mapping
of the Quezon City Hall.
-​ The system does not support online basis for the mapping and navigation.
-​ The system can access only inside the Quezon City Hall.
-​ The system generates information about Quezon City Hall offices only. p.17

Significance of the Study: p.18

Discusses the reasons in conducting the research - If you have few beneficiaries you can just
write it in one or two paragraph (why is it important to conduct the study & all the beneficiaries
and how they can benefit from the study)

-​ 1st paragraph – (Why is it important to conduct this study)

-​ 2nd paragraph – main beneficiary (organization)
-​ 3rd paragraph – secondary beneficiary
-​ 4th paragraph – importance to the proponents/researchers
-​ 5th paragraph – importance to the future researchers p.19
//Example of Significance of the Study: In today’s fast-phasing environment, technological
advancements have transformed almost everything including computerization and
mechanization of systems and processes. This study provides an efficient and effective
assessment system for Quezon City Polytechnic University.// p.20

Operational Definitions of Terms: p.23

Key terms or phrases only used in the study - Brief but clear definitions

//Example of Operational Definitions of Terms:

-​ Administrator: It is a person who handles and manages
the whole process on the Information Mapping Directory
System using Kiosk for Quezon City Hall.// p.24

WEEK 2: Software & Software Engineering

Nature of Software Engineering:

(1) instructions (computer programs) that when executed provide
desired features, function, and performance; (2) data structures that
enable the programs to adequately manipulate information, and (3)
descriptive information in both hard copy and virtual forms that
describes the operation and use of the programs. p.4
Software Characteristics:
-​ Software is developed or engineered; it is not manufactured in the
classical sense.
-​ Software doesn’t “wear out.”
-​ Although the industry is moving toward component-based
construction, most software continues to be custom built. p.5

Software Application Domains:

-​ System Software: collection of programs written to service other programs. Some
system software (e.g., compilers, editors, and file management utilities) process complex,
but determinate, information structures. Other systems applications (e.g., operating
system components, drivers, telecommunications processors) process largely
indeterminate data. p.7

-​ Application Software: stand-alone programs that solve a specific business need.

Applications in this area process business or technical data in a way that facilitates
business operations or management/technical decision making. p.8
 -​ Engineering/Scientific Software: Engineering and scientific software have been
characterized by "number crunching" algorithms. Applications range from astronomy
to volcanology, from automotive stress analysis to space shuttle orbital dynamics, and
from molecular biology to automated manufacturing. p.9

-​ Embedded Software: resides within a product or system and is used to implement and
control features and functions for the end user and for the system itself. P.10

-​ Product-line Software: designed to provide a specific capability for use by many

different customers. p.10

-​ Web Applications: called “WebApps,” this network-centric software category spans a

wide array of applications. In their simplest form, WebApps can be little more than a set
of linked hypertext files that present information using text and limited graphics. p.11

-​ Artificial Intelligence (AI) Software: makes use of nonnumerical algorithms to solve

complex problems that are not amenable to computation or straightforward analysis.
Applications within this area include robotics, expert systems, pattern recognition
(image and voice), artificial neural networks, theorem proving, and game playing. p.11

Evolving Role of Software: As a Product & As the Vehicle to Deliver the Product. p.12

Software Engineering: is an engineering approach on a software

development of systematic application. It is a process of analyzing
user needs and designing, constructing, and testing end-user
applications that will satisfy these needs through the use of software
programming languages. p.14
A generic process framework for software engineering encompasses five activities: p.18
-​ Communication
-​ Planning
-​ Modeling
-​ Construction
-​ Deployment
Software Myths:
-​ Management Myths: Managers with software responsibility, like managers in most
disciplines, are often under pressure to maintain budgets, keep schedules from slipping,
and improve quality. p.23
-​ Customer Myths: A customer who requests computer software may be a person at the
next desk, a technical group down the hall,the marketing/sales department, or an
outside company that has requested software under contract.
-​ Practitioner's Myths: Myths that are still believed by software practitioners have been
fostered by 50 years of programming culture. During the early days of software,
programming was viewed as an art form.

WEEK 3 - 4: The Software Process

Software Process: A process was defined as a collection of work activities, actions, and tasks that
are performed when some work product is to be created. Each of these activities, actions, and
tasks reside within a framework or model that defines their relationship with the process and
with one another. p.3

Process Flow: This aspect was called process flow that describes how the framework activities
and the actions and tasks that occur within each framework activity are organized with respect
to sequence and time. p.5
Process Patterns: Process patterns provide an effective mechanism for addressing problems
associated with any software process. The patterns enable you to develop a hierarchical process
description that begins at a high level of abstraction (a phase pattern). p.8

-​ Ambler: has proposed a template for describing a process pattern:

-​ Pattern Name: The pattern is given a meaningful name describing it within the context
of the software process (e.g., Technical Reviews).
-​ Forces: The environment in which the pattern is encountered and the issues that make
the problem visible and may affect its solution.
-​ Type: The pattern type is specified.

Ambler Process Pattern Types:

1.​ Stage Pattern: defines a problem associated with a framework activity for the process.
Since a framework activity encompasses multiple actions and work tasks, a stage
pattern incorporates multiple task patterns (see the following) that are relevant to the
stage (framework activity). An example of a stage pattern might be Establishing
Communication. This pattern would incorporate the task pattern Requirements
Gathering and others. p.10
2.​ Task Pattern: defines a problem associated with a software engineering action or work
task and relevant to successful software engineering practice (e.g., Requirements
Gathering is a task pattern). p.11
3.​ Phase Pattern: define the sequence of framework activities that occurs within the
process, even when the overall flow of activities is iterative in nature. An example of a
phase pattern might be Spiral Model or Prototyping. p.11
Process Patterns: Initial Context, Resulting Context, Related Patterns, & Known Uses &
Examples.

Process Assessment & Improvement:

-​ Standard CMMI Assessment Method for Process Improvement (SCAMPI): provides a
five-step process assessment model that incorporates five phases: initiating, diagnosing,
establishing, acting, and learning. The SCAMPI method uses the SEI CMMI as the basis
for assessment. p.16
-​ CMM-Based Appraisal for Internal Process Improvement (CBA IPI): provides a
diagnostic technique for assessing the relative maturity of a software organization; uses
the SEI CMM as the basis for the assessment [Dun01]. p.17
-​ SPICE (ISO/IEC15504): a standard that defines a set of requirements for software
process assessment. The intent of the standard is to assist organizations in developing an
objective evaluation of the efficacy of any defined software process. p.17
-​ SPICE (ISO/IEC15504): a standard that defines a set of requirements for software
process assessment. The intent of the standard is to assist organizations in developing an
objective evaluation of the efficacy of any defined software process. p.18

Prescriptive Process Models: were originally proposed to bring order to the chaos of software
development. History has indicated that these traditional models have brought a certain amount
of useful structure to software engineering work and have provided a reasonably effective road
map for software teams. However, software engineering work and the product that it produces
remain on “the edge of chaos.” p.19

V-Model: A variation in the representation of the waterfall model is called the V-model. The
V-model depicts the relationship of quality assurance actions to the actions associated with
communication, modeling, and early construction activities. As a software team moves down the
left side of the V, basic problem requirements are refined into progressively more detailed and
technical representations of the problem and its solution. Once code has been generated, the
team moves up the right side of the V, essentially performing a series of tests (quality assurance
actions) that validate each of the models created as the team moved down the left side. p.21
Incremental Process: The incremental model combines elements of linear and parallel process
flows. the incremental model applies linear sequences in a staggered fashion as calendar time
progresses. Each linear sequence produces deliverable “increments” of the software in a manner
that is similar to the increments produced by an evolutionary process flow. p.23

Evolutionary Model:
Prototyping: The incremental model combines elements of linear and parallel process flows.
the incremental model applies linear sequences in a staggered fashion as calendar time
progresses. Each linear sequence produces deliverable “increments” of the software in a manner
that is similar to the increments produced by an evolutionary process flow. p.26
Spiral Model: Originally proposed by Barry Boehm [Boe88], the spiral model is an evolutionary
software process model that couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model. It provides the potential for rapid development of
increasingly more complete versions of the software. Boehm [Boe01a] describes the model in the
following manner. p.28

Concurrent Model: The concurrent development model, sometimes called concurrent

engineering, allows a software team to represent iterative and concurrent elements of any of the
process models described in this chapter. For example, the modeling activity defined for the
spiral model is accomplished by invoking one or more of the following software engineering
actions: prototyping, analysis, and design. p.30

Specialized Process Model: Specialized process models take on many of the characteristics of
one or more of the traditional models presented in the preceding sections. However, these
models tend to be applied when a specialized or narrowly defined software engineering
approach is chosen. P.31
●​ Component-Based Development Model p.32
●​ Formal Methods Model p.33

Unified Process: is an attempt to draw on the best features and characteristics of traditional
software process models, but characterize them in a way that implements many of the best
principles of agile software development. The Unified Process recognizes the importance of
customer communication and streamlined methods for describing the customer’s view of a
system. It emphasizes the important role of software architecture and “helps the architect focus
on the right goals, such as understandability, reliance to future changes, and reuse”. It suggests
a process flow that is iterative and incremental, providing the evolutionary feel that is essential
in modern software development. p.35
* Inception Phase
* Elaboration Phase
* Construction Phase
* Transition Phase
* Production Phase

Personal Software Phase:

-​ Planning: This activity isolates requirements and develops both size and resource
estimates. All metrics are recorded on worksheets or templates. Finally, development
tasks are identified and a project schedule is created. p.43
-​ High-Level Design: External specifications for each component to be constructed are
developed and a component design is created. Prototypes are built when uncertainty
exists. All issues are recorded and tracked. p.44
-​ High-Level Design Review: Formal verification methods (Chapter 21) are applied to
uncover errors in the design. Metrics are maintained for all important tasks and work
results. p.44
-​ Development: The component-level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work
results. p.45
-​ Postmortem: Using the measures and metrics collected (this is a substantial amount of
data that should be analyzed statistically), the effectiveness of the process is determined.
Measures and metrics should provide guidance for modifying the process to improve its
effectiveness. p.45
WEEK 5 - 6: Managing Software Projects

Project Management Concepts:

●​ Software Project Management: Refers to the branch of project management dedicated
to planning, scheduling, resource allocation, execution, tracking and delivery of software
and web project.
Process & Project Metrics:
Software Management Activities, Project Planning, Scope Management
Project Scope Management Necessaries:
●​ Define the scope
●​ Decide its verification and control
●​ Divide the project into various smaller parts for ease of management.
●​ Verify the scope
●​ Control the scope by incorporating changes to the scope

Project Estimation:
●​ Software Size Estimation
●​ Effort Estimation
●​ Time Estimation
●​ Cost Estimation
Estimating Project Cost Required to Consider:
●​ Size of software
●​ Software quality
●​ Hardware
●​ Additional software or tools, licenses etc.
●​ Skilled personnel with task-specific skills
●​ Travel involved
●​ Communication
●​ Training and support

Estimation for Software Projects:

●​ Decomposition Technique: This technique breaks down the project into smaller
components to estimate effort and cost accurately.
-​ Line of Code Estimation: This technique estimates effort based on the expected
number of lines of code in the software.
-​ Function Points Estimation: This technique estimates effort based on functional
user requirements rather than code size.

●​ Empirical Estimation Technique: method used in statistics and research to estimate

unknown parameters or outcomes based on observed data rather than theoretical
models or assumptions. It relies on actual data collected from experiments, surveys, or
observations to estimate quantities or predict future outcomes.
-​ Putnam Model: The Putnam Model is based on the Rayleigh Curve and helps
estimate effort, cost, and time using historical productivity data.
 -​ COCOMO - The COCOMO Model is a widely used empirical estimation model
developed by Barry Boehm. It estimates effort, cost, and time based on software size
(LOC) and project type.

(Planning and Requirements, System Design, Detailed Design, Module Code and Test,
Integration and Test, & Cost Constructive Model. TOP to BOTTOM)

Project Scheduling (Activities):

●​ Break down the project tasks into smaller, manageable form
●​ Find out various tasks and correlate them
●​ Estimate time frame required for each task
●​ Divide time into work-units
●​ Assign adequate number of work-units for each task
●​ Calculate total time required for the project from start to finish

Resource Management:
●​ Defining proper organization project by creating a project team and allocating
responsibilities to each team member
●​ Determining resources required at a particular stage and their availability
●​ Manage Resources by generating resource request when they
●​ are required and de-allocating them when they are no longer needed.

Risk Management (Project Risk Management):

●​ Experienced staff leaving the project and new staff coming in.
●​ Change in organizational management.
●​ Requirement change or misinterpreting requirements.
●​ Under-estimation of required time and resources.
●​ Technological changes, environmental changes, business competition.
Risk Management Process:
●​ Identifications: This step involves recognizing potential risks that may affect the project.
How to Identify Risks?
-​ Brainstorming with team members
-​ Reviewing past project failures
-​ Analyzing business and technical challenges
-​ Using risk checklists
●​ Categorize: Once risks are identified, they are grouped into categories based on their
nature and impact.

●​ Manage: Develop strategies to handle risks, either by eliminating, reducing,

transferring, or accepting them.

●​ Monitor: Continuously track risks throughout the project lifecycle to ensure they are
controlled.
How to Monitor Risks?
-​ Regular status meetings
-​ Risk tracking tools (e.g., Excel sheets)
-​ Periodic risk reassessments

Project Execution & Monitoring:

●​ Activity Monitoring: Tracking work progress to make sure everything is going as
planned.
●​ Status Reports: A summary of work progress shared with the team or management.
●​ Milestones Checklist: A list of important project goals to track progress.
Software Management Activities:
●​ Project Communication Management: Managing how information is shared in a project
to ensure everyone is on the same page.
-​ Planning: Deciding How, When, and Who will communicate in the project.
-​ Sharing: Sending updates, documents, and reports to keep everyone informed.
-​ Feedback: Team members and stakeholders give Suggestions, Approvals, or
Concerns.
-​ Closure: Final communication to Wrap Up the project and document
everything.
●​ Configuration Management(CM): is the Process of Managing and Tracking Changes in
a system, software, or project to ensure consistency and reliability.
-​ Identification: Finding and defining All Components that need to be tracked and
managed.
-​ Validation: Checking if the identified items Meet the Required Standards and
are properly recorded.
-​ Analysis: Studying proposed changes to Assess their Impact on the system.
-​ Control Execution: Managing and approving Changes to ensure they don’t
disrupt stability and Implementing Approved Changes while ensuring no errors
occur.
-​ Close request: Finalizing and documenting the changes made to ensure tracking
and accountability.

Project Management Tools: help and assist an individual or team to plan,

organizing and managing work projects and tasks effectively from start to
finish.
-​ Critical Path Analysis: is useful in recognizing interdependent tasks in the
project. It also helps to find out the shortest path or critical path to
complete the project successfully.

●​ GANTT CHART: was devised by Henry Gantt (1917). It represents the project schedule
with respect to time periods. It is a horizontal bar chart with bars representing activities
and time scheduled for the project activities.
 ●​ PERT CHART (Program Evaluation & Review Technique) Chart: is a tool that depicts
a project as a network diagram. It is capable of graphically representing main events of
a project in both parallel and consecutive ways.
-​ CPM (Critical Path Method): is a network analysis technique used in planning,
scheduling and controlling of complex but routine activities

●​ Resource Histogram: This is an effective graphical tool for staff planning and
coordination that contains a bar or chart representing the number of resources (usually
skilled staff) required overtime for a project event (or phase).

Maintenance and Reengineering:

●​ Software Maintenance:
-​ It begins almost immediately after software is released to end users.
-​ Maintenance corrects defects, adapts the software to meet a changing
environment, and enhances functionality to meet the evolving needs of
customers.
●​ Reengineering:
-​ At a strategic level, Business Process Reengineering (BPR) defines business
goals, identifies and evaluates existing business processes, and creates revised
business processes that better meet current goals.
●​ Software Reengineering:
-​ encompasses inventory analysis, document restructuring, reverse engineering,
program and data restructuring, and forward engineering. The intent of these
activities is to create versions of existing programs that exhibit higher quality
and better maintainability.