Prelims - Siaa
Prelims - Siaa
WITH LAB
SYSTEM ANALYST
SYSTEM ANALYST WEEK 1
A system analyst is someone who is in charge of
designing, transforming, modifying, and
evaluating different systems to ensure
SYSTEM ANALYST SKILLS
compatibility and users’ efficiency and
TECHNICAL effectiveness and also turns user requirements
into a set of functional specifications, which are
Understand the potential and limitations of
the blueprint of the system.
information technology. It helps to understand
how computers, data networks, databases, and Duties of System Analysis
operating systems work together. The system
• Consulting with management and users to
analyst must also be able to work with complex
determine the needs of the system.
programming languages.
• Designing a system to meet the business
BUSINESS objectives and goals.
• Specifying inputs and formatting outputs
defined as the value of the business. It
to meet users’ needs.
encompasses all elements that determine the
well-being and health of a business. BUSINESS ANALYST
ANALYTICAL A business analyst is a person who analyzes,
organizes, explores, and investigates an
The ability to collect and analyze data is essential
organization documents its business and also
for a business systems analyst. In this role, you
assesses the business model, and integrates the
must understand the data and identify trends to
whole organization with modern technology.
make recommendations to improve the system.
Business analyst acts as a bridge and channel
INTERPERSONAL
between the clients, consumers, and the
or also known as people skills are the vital skills a development team. Business development and
person uses to communicate and/or interact with requirements are translated, transformed, and
others including persuasion, delegation, and interpreted to functional specifications by a
active listening. These skills are extremely business analyst.
important as they help the system analyst work
REQUIREMENTS ANALYST
with other system professionals, programmers,
and importantly the end users. A requirements analyst is the person who elicits,
analyzes, validates, and manages the
MANAGEMENT
requirements throughout the project lifecycle.
help the system analyst manage projects, their
Eliciting requirements
resources, the possible threats and risks, and
finally the ongoing changes. This ability to make involve asking the right questions, listening
decisions, understand concepts, develop ideas, actively, observing behaviors, and facilitating
and implement strategies proves very important workshops or interviews.
for a system analyst.
Analyzing requirements
ETHICAL
ensure that they are clear, consistent, complete,
professionalism, respect for the work and feasible, and testable. Validating requirements
teammates, integrity, timeliness, and discipline. ensure that they meet the expectations and needs
of the stakeholders and users.
LA
Validating requirements They ensure smooth communication across the
company during the changeover process, often
involves reviewing, verifying, and validating the
using technological tools such as Sharepoint to
requirements with the relevant parties, as well as
make sure that everyone is on the same page.
conducting tests, prototypes, or simulations.
PROJECT MANAGER
Managing requirements
Project managers play the lead role in planning,
ensure that they are aligned with the project
executing, monitoring, controlling and closing
scope, objectives, and changes. Managing
projects.
requirements involves documenting, tracing,
baselining, and controlling the requirements They are accountable for the entire project
throughout the project lifecycle. scope, the project team and resources, the
project budget, and the success or failure of the
Communicating requirements
project. To succeed in their role, project
ensure that they are understood and agreed by all managers must be adept at coordinating
the project participants. Communicating resources, managing budgets, measuring and
requirements involves creating, presenting, and tracking project progress, and communicating
distributing the requirements artifacts, such as with team members and stakeholders.
specifications, diagrams, or user stories.
System Design and Life Cycle
Improving requirements
refers to a methodology with clearly defined
ensure that they are continuously refined and processes for creating high-quality software. In
optimized. Improving requirements involves detail, the SDLC methodology focuses on the
evaluating, measuring, and improving the following phases of software development:
requirements process, methods, and outcomes.
• Requirement analysis
INFRASTRUCTURE ANALYST • Planning
• Software design such as architectural
An infrastructure analyst finds and fixes problems
design
within an organization’s computer network. As an
infrastructure analyst, your job duties include • Software development
monitoring and assessing the systems and finding • Testing
areas that need upgrading or improvement. • Deployment
LA
STAGES & BESTPRACTICES 5. Code Test
Following the best practices and/or stages of “Did we get what we want?” In this stage, we test
SDLC ensures the process works in a smooth, for defects and deficiencies. We fix those issues
efficient, and productive way. until the product meets the original specifications.
1. Identify the Current Problems In short, we want to verify if the code meets the
defined requirements.
“What are the current problems?” This stage of
the SDLC means getting input from all 6. Software Deployment
stakeholders, including customers, salespeople,
“Let’s start using what we got.”
industry experts, and programmers. Learn the
strengths and weaknesses of the current system At this stage, the goal is to deploy the software to
with improvement as the goal. the production environment so users can start
using the product. However, many organizations
2. Plan
choose to move the product through different
“What do we want?” In this stage of the SDLC, deployment environments such as a testing or
the team determines the cost and resources staging environment.
required for implementing the analyzed
PROJECTIDENTIFICATION
requirements. It also details the risks involved and
provides sub-plans for softening those risks. 1. Business Identification
2. Emerging Technology
In other words, the team should determine the
3. Reengineering
feasibility of the project and how they can
implement the project successfully with the
lowest risk in mind.
3. Design
“How will we get what we want?” This phase of
the SDLC starts by turning the software
specifications into a design plan called the Design
Specification. All stakeholders then review this
plan and offer feedback and suggestions. It’s
crucial to have a plan for collecting and
incorporating stakeholder input into this
document. Failure at this stage will almost
certainly result in cost overruns at best and the
total collapse of the project at worst.
4 Build
“Let’s create what we want.”
At this stage, the actual development starts. It’s
important that every developer sticks to the
agreed blueprint. Also, make sure you have
proper guidelines in place about the code style
and practices.
LA
FEASIBILITY ANALYSIS WEEK 2 TECHNICAL FEASIBILITY
FEASIBILITY ANALYSIS Technical feasibility inspects whether software
can be built at all with available tools and
A feasibility study, or feasibility analysis, assesses
experts. In software engineering, technical
the viability of the project idea from different
feasibility (TF) is the most timeconsuming and
perspectives. Its goal is to help top managers
complex part of the full feasibility analysis.
narrow down alternatives and make informed
go/no-go decisions. Feasibility is assessed at the ideation phase of
product development, after gathering early
• Ensures the analysis of every small aspect
project requirements — namely
ofthe feasibility of the proposed software
orproject. • functional requirements, captured by
• Help you analyze for multiple purposes to business analysts and describing features
understand whether the software will be of the solution; and
able to withstand the market or not. • non-functional requirements, usually
• Helps developers understand the product collected by a software architect and
in the right terms from the point of view of related to the properties of the system —
development, implantation, the like performance, scalability, and so on.
contribution of the project to the
DIFFERENCE BETWEEN FUNCTIONAL AND NON-
organization.
FUNCTIONAL REQUIREMENTS:
For example, Cedric wants to launch a new home
decor business. So, he evaluates factors like
potential profitability, effect on the environment,
legal requirements, etc. It is his feasibility study,
and based on the findings, he can decide whether
or not to move forward with the project.
LA
EXAMPLES OF FUNCTIONAL AND NON- development projects that breach the law are
FUNCTIONAL REQUIREMENTS: legally not feasible.
Functional Requirements Example: OPERATIONAL FEASIBILITY
LA
Examples of guiding questions are: called a Software Requirement Specification
(SRS). It contains:
• Does implementing the new system
require new technology? • Details of the problem
• The scope of work, and is it within the • Alternative solutions
system development budget? • Software system requirements
• Answers to these and other questions are • System constraints
all aspects of the assessment phase.
05 Systems Specification
02 Gathering Information
It contains detailed instructions, file definitions,
In this phase, the team collects views and ideas flowcharts, and other diagrams. Along the way,
from users. They must concisely define and analysts and system users engage in
document the user requirements. Failure to nail brainstorming sessions. The two teams meet
this step often results in a faulty end product. In regularly as the project progresses. In this phase,
addition, the requirements should drill down to also called the design phase, software engineers
different user levels. transform the SRS document into a software
architecture.
Typically, the software development team will
interview end users inside an organization. They 06 Programming
will also request that external users, i.e.,
Upon verifying and checking that the system’s
customers and suppliers, share feedback. On the
specification is accurate and verified,
other hand, if an organization is modifying its
programmers take over. They write and test the
existing systems, the team will review the
software codes. Numerous tests get underway
documentation.
using automated tools and quality assurance
03 Drafting a Feasibility Study Report checks. Module testing also takes place at this
stage. It follows a structured approach, defining a
It contains findings and recommendations. The
test plan, testing criteria, and managing test
report states whether the company should
cases. Debugging takes place in this stage too.
develop new software or improve the existing
system. The software review team highlights 07 Production
budgetary changes and an estimated work
After testing the system thoroughly, production
completion schedule.
or changeover takes place. End-users undergo
Also in the report are references to documents thorough training. The system development team
reviewed and definitions of terms used, including stays on alert to respond to queries and correct
abbreviations and acronyms. Risks and delays various errors that crop up. A system at this stage
that may be encountered during implementation takes several weeks before reaching stability.
also form part of the report’s contents.
08 Evaluation
04 Requirements Analysis
Once the system stabilizes, an evaluation of its
Once a study returns a feasible verdict, the client correctness gets underway. There is an entire list
gives the go-ahead. The first step is to conduct a of things that need correcting. Besides, the team
systems analysis. At this point, analysts must also contend with unanticipated issues.
determine the bones and flesh of the new Further, the integration of software modules
system. takes place in this phase.
What inputs will it need? What output shall it The software development engineers test each
generate? Will it need paper forms and external module before adding the next one and testing
files? Answers to these and other queries go into again. It is an incremental process. The team
a requirements document. This document is seeks to ascertain whether the software
LA
conforms to the SRS document’s requirements. CREATING THE PROJECT PLAN WEEK 3
Once all modules were in place, they tested the
What is a Software Project Plan?
system as a fully developed product. There are
three system testing phases: Alpha, Beta, and A software project plan is a collection of
Acceptance. Alpha testing is done at the software documents that outline the tasks and timeline of
developer’s site. Beta testing targets customers, your software development.
while the client does Acceptance testing.
• Software project plans usually follow
09 Implementation flexible progressions that allow project
managers to adjust for project success.
After months of designing, training, and
• A flexible project plan enables software
stabilizing a system, the next phase is
developers to move forward and back in
implementing it. Programmers have already
creating error-free programs because a
tested the software and are confident that it
large part of software development
meets the organization’s requirements.
comprises testing and troubleshooting.
Implementation of feasibility studies in software
engineering takes place in two phases. In the first Importance of Software Project Plans
phase, the client gets a trial version of the
software as an experiment to determine whether • Defining role and responsibilities
any changes are needed. Users are encouraged to • Determining client requirements
share feedback on the system’s operation. • Meeting project deadlines
• Adhering to the project budget
• The complete system is delivered to the • Ensuring high-quality work
client during the second implementation
phase. Even more importantly, the system How to create a Software Project Plan
must be secure. Note, a system delivery 1. DEFINE THE SCOPE OF YOUR SOFTWARE
could replace a manual system, a new PROJECT
system, or a modification.
A project' s scope describes the goals needed to
10 Maintenance complete the project successfully. When defining
Software maintenance is a critical stage in the your scope, consider project aspects like
system development life cycle. Even though outcomes, tasks, budget, time frame, and
maintenance is a rewarding experience, it can deliverables.
also be time-consuming. Types of maintenance 2. ISOLATE TASKS WITHIN THE PROJECT
carried out are corrective, adaptive, perfective,
and preventive. When creating a software project plan, it' s
helpful to isolate the smaller tasks that comprise
• Corrective: Involves correcting past the project. This can help determine the project
problems or repairing current budget and create a team to manage aspects of
performance failures. the project.
• Adaptive: Changing the system so that it is
in sync with the external environment, For example, you may want to create a team that
e.g., changes in taxation. performs quality assurance on the beta code for
• Perfective: Enhancement or modification the software. In your document, make a list of the
to match changing needs. separate tasks that lead to a completed project.
• Preventive: This is the maintenance 3. DESIGN TIME-BASED OBJECTIVES
process to prevent the system from
becoming obsolete. Deciding on your time-based objectives, or
milestones, is an important step in software
LA
project planning. To do this, determine how long budget and time estimates remain correct.
each task within the project should take. Understanding how each aspect of the project
plan and its actual work compare is important for
For example, if you have six months to develop
creating a realistic plan.
software for your client, you might want to finish
the program prototype by the second month of 8. MAKE ADJUSTMENTS TO ENSURE SUCCESS
the project. Create deadlines or milestones within
Using your project data, make necessary
the project, giving yourself extra time to account
adjustments to the project scope, how you
for any delays.
implement your plan or the delegation of tasks.
4. DELEGATE TASKS TO TEAMS OR INDIVIDUALS For software projects, it' s important to maintain
a flexible plan so that you can adapt it as needed.
If a task within your project is complex or may
After you collect data from your team or client,
require specific expertise, consider creating a
analyze this data to see if you need to make
team of skilled individuals to work together.
changes.
For example, you may have one team work on
CREATING THE PROJECT PLAN
design while another performs software sprints,
quality assurance and testing. PROJECT MANAGEMENT PHASES CONSIST OF
5. ESTABLISH SCHEDULES FOR YOUR TEAM • Stage 1: Project Conception and Initiation
• Stage 2: Project Planning
Once you know when to complete each task
• Stage 3: Project Execution
within the project, you can establish schedules
for everyone working on the software. Detailing • Stage 4: Project Monitoring & Controlling
how much labor you need and communicating • Stage 5: Project Close
with your team about the project needs can help PROJECT METHODOLOGY OPTIONS
you reach your milestones on time and ensure
timely deliverables. • Waterfall Development
• Parallel Development
For example, if you expect to finish the project in • V-model
six months, you can create a monthly schedule • Rapid Application Development (RAD)
that details what each team should work on
• Iterative Development
during that month.
• System prototyping
6. PERFORM APPROPRIATE RISK ASSESSMENTS • Agile Development
There ' s some risk for every project, and by Waterfall Development
performing risk assessments, you can identify
is a sequential development process that flows
obstacles that could affect your project.
like a waterfall through all phases of a project.
For example, if you rely on a stable internet
connection to complete your work, a system
failure in the fiber optics network might be a risk.
By performing risk assessments, you can
anticipate potential risk factors and prepare plans
for adapting to them.
7. GATHER AND ANALYZE PROJECT DATA
Gathering and analyzing data is an important part
of the software planning process because it helps
ensure the success of your current plan.
Gathering project data can determine if your
LA
Parallel Development Rapid Application Development: System
Prototyping
is working on multiple projects or features at the
same time. allows you to design a working “prototype” or
early sample of what' s to come.
V-Model
Throwaway Prototyping
Is an SDLC model where execution of processes
Building initial ideas for different applications,
happens in a sequential manner in a V-shape.
interfaces, or functions, without necessarily
having the intention of including them in the
finished system.
LA
Selecting the Appropriate Methodology PROJECT CHARTER
• A project charter is a short document
used in project planning to outline the key
aims and benefits of a project.
• Describes the project’s objectives and
rules.
FUNCTIONAL LEAD
• Manages a group of Analysts.
IMPORTANT FACTORS TO CONSIDER IN TECHNICAL LEAD
SELECTING THE DEVELOPMENT METHODOLOGY
• Oversees the progress of programmers
• Clarity of User Requirements and technical staff members.
• Familiarity with Technology
• System Complexity
• System Reliability MOTIVATION
• Short Time Schedules
• DON’T ASSIGN UNREALISTIC DEADLINES
• Schedule Visibility
• DON’T IGNORE GOOD EFFORTS
• DON’T CREATE A LOW-QUALITY PRODUCT
STAFFING THE PROJECT WEEK 4 • DON’T GIVE EVERYONE ON THE PROJECT
A RAISE
STAFFING PLAN • DON’T MAKE AN IMPORTANT DECISION
WITHOUT THE TEAM’S INPUT
Staffing is that part of management concerned
with obtaining, utilizing, and maintaining capable • DON’T MAINTAIN POOR WORKING
people to fill all positions in the organization from CONDITION
top level to bottom level. It involves the scientific
and systematic procurement, allocation,
utilization, conservation, and development of HANDLING CONFLICT
human resources. • CLEARLY DEFINE PLANS FOR THE PROJECT.
• Describes the kinds of people working on • RECOGNIZE PROJECT IMPORTANCE TO
the project. THE ORGANIZATION.
• Staffing levels will change over a project’s • PROJECT CHARTER LISTING NORMS AND
lifetime. GROUND RULES.
• Adding staff may add more overhead than • DEVELOP SCHEDULE COMMITMENTS
additional labor. AHEAD OF TIME.
• It ensures that the organization has the • FORECAST OTHER PRIORITIES AND THEIR
correct number of people at the right POSSIBLE IMPACT ON THE PROJECT.
places, time, and performing the right
thing.
COORDINATING PROJECT ACTIVITIES
REPORTING STRUCTURE
CASE
• CASE stands for Computer Aided Software
Engineering.
• It means the development and
maintenance of software projects with
the help of various automated software
tools.
LA
CASE TOOLS System Integration and Architecture 311 Week 5
• CASE tools are a set of software MANAGING AND CONTROLLING THE PROJECT
application programs, which are used to
The science (or art) of project management is in
automate SDLC activities.
making trade-offs among three important
• CASE tools are used by software project
concepts:
managers, analysts, and engineers to
develop software systems. • The size of the system,
• The time to complete the project,
• The cost of the project.
COMPONENTS OF CASE TOOLS
TOOLS FOR PROJECT MANAGEMENT – EXAMPLE
CENTRAL REPOSITORY OF GANTT CHART
Central Repository CASE tools require a central
repository, which can serve as a source of
common, integrated, and consistent information.
• A central repository is a central place of
storage where product specifications,
requirement documents, related reports
and diagrams, and other useful
information regarding management is
stored. Central repository also serves as REFINING ESTIMATES
data dictionary.
The estimates produced during the planning
UPPER CASE TOOLS phase must be refined as the project progresses.
This does not necessarily mean that estimates
are used in the planning, analysis, and design
were poorly done at the start of the project; it is
stages of SDLC
virtually impossible to develop an exact
LOWER CASE TOOLS assessment of the project’s schedule before the
analysis and design phases are conducted.
are used in implementation, testing, and
maintenance.
INTEGRATED CASE TOOLS
are helpful in all the stages of SDLC, from
Requirement gathering to Testing and
documentation.
MANAGING SCOPE
SCOPE CREEP
• The most common reason for schedule
and cost overruns occur after the project
is underway.
• Scope creep can occur during a project
when a client adds tasks outside of the
scope of your agreement.
LA
The project manager should allow only necessary • Implement risk responses as early as
requirements to be added after the project possible. ...
begins. • Track them down regularly.
A Gantt chart is a horizontal bar chart that shows
the same task information as the project work
TIMEBOXING
plan but in a graphical way.
Is a feature of software development technology
that plans and allots time boxes for different
activities.
• Set a fixed deadline for a project
• Reduce functionality, if necessary
• Don’t get hung up on the final “finishing
touches”
TIMEBOXING STEPS
1. Set the date for system delivery.
2. Prioritize the functionality that needs to
be included in the system.
3. Build the core of the system (the
functionality ranked as most Important).
4. Postpone funtionality that cannot be
provided within the time frame.
5. Deliver the system with core functionality.
6. Repeat steps 3 through 5, to add
refinements and enhancements.
RISK ASSESSMENT
• an important step in being prepared for
potential problems that can occur within
any software project. During the risk
assessment, if a potential risk is identified,
a solution or plan of action should be
developed.
For example, they do a risk assessment after the
project manager and team identify the risk of
water damage to downtown buildings due to
hurricane-induced flooding.
LA