 DFD

 Use Case
 RMM
 CMMI
 SQA
 ISO 9000 Quality Standards

SOFTWARE
ENGINEERING

Nahed Azem
Level 0 DFD:

At the highest level of abstraction, you have the main processes and entities of
the system:

1. Patients: Individuals who seek medical services from the hospital.

2. Staff: Employees working within the hospital.
3. Administrator: The person responsible for managing the entire system.
4. Doctor: Medical professionals providing diagnosis and treatment to
patients.
5. Reception: The department responsible for handling patient inquiries,
appointments, and admissions.
6. Pharmacy: Dispensing medication to patients.
7. Laboratory: Conducting medical tests and providing reports.
8. Billing: Managing patient bills and payments.
9. Inventory: Handling the stock of medicines and other supplies.
10. Management Reports: Generating reports for hospital management.

Level 1 DFD:

Breaking down each process into more detail:

Reception:

1. Receive Patient: Receptionist receives patient details.

2. Schedule Appointment: If needed, schedules appointments.
3. Admit Patient: If required, admits patient to the hospital.

Doctor:

1. Consult Patient: Doctor consults patient.

2. Prescribe Medication: If necessary, prescribes medication or further
tests.

Pharmacy:

1. Receive Prescription: Pharmacy receives prescription from doctor.

2. Dispense Medication: Pharmacy dispenses medication to patient.

Laboratory:

1. Receive Test Request: Laboratory receives test request from doctor.

 2. Conduct Tests: Laboratory conducts tests.
3. Generate Report: Laboratory generates a report and sends it to the
doctor.

Billing:

1. Generate Bill: Billing department generates a bill for the patient.

2. Receive Payment: Billing department receives payment from the
patient.

Level 0 DFD:

At the highest level of abstraction, you have the main processes and entities of
the system:

1. Customers: Individuals dining at the restaurant.

2. Staff: Employees working within the restaurant.
3. Administrator: The person responsible for managing the entire system.
4. Kitchen: Area responsible for food preparation.
5. Front Desk/POS: Point of Sale system for order taking and payment
processing.
6. Inventory: Management of food and beverage stock.
7. Reservation System: Handling table reservations.

Level 1 DFD:

Breaking down each process into more detail:

Front Desk/POS:

1. Take Order: Staff takes customer orders.

2. Process Payment: Front desk processes payment for orders.
3. Generate Receipt: Receipt is generated for the customer.

Kitchen:

1. Receive Order: Kitchen receives order details.

2. Prepare Food: Kitchen prepares the food items.
 3. Complete Order: Kitchen completes the order and notifies the front
desk.

Inventory:

1. Receive Delivery: Inventory receives deliveries of food and beverage

stock.
2. Update Stock: Inventory updates stock levels.
3. Generate Restock Alert: Inventory generates alerts for low stock levels.

Reservation System:

1. Receive Reservation Request: Reservation system receives requests for

table reservations.
2. Check Availability: Reservation system checks table availability.
3. Confirm Reservation: Reservation is confirmed and notification is sent
to the customer.

Staff Management:

This process handles employee-related tasks such as scheduling, payroll, and

performance management.

Restaurant Management System (RMS):

1. Order Management:
o Place Order: Customers can place their orders either by visiting
the restaurant or through an online ordering system.
o Modify Order: Customers can modify their orders, such as adding
or removing items, before finalizing.
o Cancel Order: Customers can cancel their orders if needed,
subject to restaurant policies.
o Order Tracking: Customers can track the status of their orders,
from preparation to delivery or pickup.
2. Table Management:
o Table Reservation: Customers can reserve tables in advance
through the restaurant's reservation system.
o Table Assignment: Staff can assign available tables to customers
based on their preferences and party size.
 o Table Status: Staff can manage the status of tables (e.g., occupied,
reserved, available) to optimize seating arrangements.
3. Menu Management:
o Menu Display: The system displays the restaurant's menu,
including food and beverage options, prices, and descriptions.
o Menu Customization: Managers can update the menu items, add
seasonal specials, or remove discontinued items.
o Menu Item Availability: The system tracks the availability of menu
items based on inventory levels or kitchen capacity.
4. Inventory Management:
o Stock Tracking: The system monitors the stock levels of
ingredients, food items, and beverages in real-time.
o Restocking: When inventory levels fall below a certain threshold,
the system generates restocking alerts and notifies the relevant
staff members.
o Vendor Management: The system manages relationships with
suppliers and vendors for ordering stock and tracking deliveries.
5. Staff Management:
o Employee Scheduling: Managers can create employee schedules,
assign shifts, and manage time-off requests.
o Attendance Tracking: The system tracks employee attendance
and hours worked for payroll purposes.
o Performance Evaluation: Managers can conduct performance
reviews, provide feedback, and track employee performance
metrics.
6. Billing and Payment:
o Bill Generation: The system generates bills for customers based
on their orders, including itemized details and taxes.
o Payment Processing: Customers can pay their bills using various
payment methods, such as cash, credit/debit cards, or mobile
wallets.
o Splitting Bills: The system allows customers to split the bill among
multiple parties or pay separately.
7. Reporting and Analytics:
o Sales Reports: Managers can generate reports on daily, weekly, or
monthly sales performance, including revenue, average order
value, and popular menu items.
o Inventory Reports: Reports on inventory usage, wastage, and cost
analysis help in optimizing inventory management.
 o Customer Insights: Analyzing customer data and preferences
helps in creating targeted marketing campaigns and improving
customer satisfaction.

1. Risk Identification:

1. Scope Creep: There's a risk of expanding project scope beyond initial

requirements due to evolving stakeholder expectations.
2. Technology Risks: Integration challenges with existing hospital systems,
compatibility issues with hardware/software, or reliance on outdated
technologies.
3. Data Security: Risks associated with the storage, transmission, and
protection of sensitive patient information, including the risk of data
breaches.
4. Regulatory Compliance: Failure to comply with healthcare regulations
and standards, leading to legal and financial consequences.
5. Resource Constraints: Limited availability of skilled personnel, time, and
budget constraints impacting project timelines and deliverables.
6. User Adoption: Resistance from hospital staff to adopt new technology
or lack of training leading to underutilization of the HMS.
7. Vendor Risks: Dependency on third-party vendors for software
components or services, including the risk of vendor lock-in or
bankruptcy.

2. Risk Assessment:

For each identified risk, assess the likelihood and potential impact on the
project. Prioritize risks based on their severity to focus mitigation efforts on
high-risk areas.

3. Risk Mitigation:

1. Scope Management: Define clear project scope, objectives, and

deliverables. Implement change control procedures to manage scope
creep effectively.
2. Technology Assessment: Conduct thorough technology evaluations and
compatibility tests. Use modern, secure, and scalable technologies for
the HMS development.
 3. Security Measures: Implement robust data encryption, access controls,
and authentication mechanisms to protect patient data. Conduct regular
security audits and penetration testing.
4. Compliance Measures: Stay updated with healthcare regulations and
standards (e.g., HIPAA). Involve legal experts to ensure compliance
throughout the project.
5. Resource Planning: Allocate resources effectively, considering skill sets,
availability, and workload. Identify potential resource constraints early
and plan contingencies.
6. Change Management: Develop a comprehensive change management
plan, including communication, training, and support strategies to
facilitate user adoption.
7. Vendor Management: Perform due diligence when selecting vendors.
Establish clear contractual agreements, service level agreements (SLAs),
and contingency plans.

4. Risk Monitoring and Control:

Regularly monitor identified risks, assess their status, and implement

appropriate control measures:

 Conduct regular risk reviews and updates to the risk register.

 Implement risk response strategies as needed, such as risk avoidance,
mitigation, transfer, or acceptance.
 Communicate risk status and mitigation efforts to stakeholders regularly.
 Continuously monitor project progress and adjust risk management
strategies as necessary.

By implementing a proactive risk management approach, you can mitigate

potential threats to the successful development and implementation of the
Hospital Management System.

Developing a Restaurant Management System (RMS) involves various risks that

need to be addressed to ensure the success of the project. Here's a risk
management plan tailored to the development of an RMS:

1. Risk Identification:

1. Scope Creep: The risk of the project expanding beyond the initial
requirements due to evolving stakeholder expectations.
 2. Technology Risks: Challenges related to integrating with existing
systems, compatibility issues, or reliance on outdated technologies.
3. Data Security: Risks associated with storing and protecting sensitive
customer data, including the risk of data breaches.
4. Regulatory Compliance: Failure to comply with food safety regulations,
health codes, and payment processing standards.
5. Resource Constraints: Limited availability of skilled personnel, budget
constraints, and time constraints impacting project timelines and
deliverables.
6. User Adoption: Resistance from restaurant staff to adopt new
technology or lack of training leading to underutilization of the RMS.
7. Vendor Risks: Dependency on third-party vendors for software
components or services, including the risk of vendor lock-in or
bankruptcy.
8. Market Competition: Competition from existing restaurant
management systems or emerging technologies impacting the success of
the RMS.

2. Risk Assessment:

For each identified risk, assess the likelihood and potential impact on the
project. Prioritize risks based on their severity to focus mitigation efforts on
high-risk areas.

3. Risk Mitigation:

1. Scope Management: Define clear project scope, objectives, and

deliverables. Implement change control procedures to manage scope
creep effectively.
2. Technology Assessment: Conduct thorough technology evaluations and
compatibility tests. Use modern, secure, and scalable technologies for
RMS development.
3. Security Measures: Implement robust data encryption, access controls,
and authentication mechanisms to protect customer data. Conduct
regular security audits and penetration testing.
4. Compliance Measures: Stay updated with food safety regulations,
health codes, and payment processing standards. Involve legal experts
to ensure compliance throughout the project.
5. Resource Planning: Allocate resources effectively, considering skill sets,
availability, and workload. Identify potential resource constraints early
and plan contingencies.
 6. Change Management: Develop a comprehensive change management
plan, including communication, training, and support strategies to
facilitate user adoption.
7. Vendor Management: Perform due diligence when selecting vendors.
Establish clear contractual agreements, service level agreements (SLAs),
and contingency plans.
8. Market Analysis: Conduct market research to understand the
competitive landscape and customer needs. Identify unique selling
points and differentiation strategies for the RMS.

4. Risk Monitoring and Control:

 Regularly monitor identified risks, assess their status, and implement

appropriate control measures.
 Conduct regular risk reviews and updates to the risk register.
 Implement risk response strategies as needed, such as risk avoidance,
mitigation, transfer, or acceptance.
 Communicate risk status and mitigation efforts to stakeholders regularly.
 Continuously monitor project progress and adjust risk management
strategies as necessary.

Risk management: Reactive vs. Proactive Risk strategies, software risks, Risk
identification, Risk projection, Risk refinement, RMMM, RMMM Plan.

Risk Management
Risk is an undesired event or circumstance that occur while a project is
underway It is
necessary for the project manager to anticipate and identify different risks that
a project may be susceptible to Risk Management. It aims at reducing the
impact of all kinds of risk that may effect a project by identifying, analyzing and
managing them
Reactive Vs Proactive risk
Reactive : It monitors the projects likely risk and resources are set aside.
Proactive: Risk are identified, their probability and impact is accessed

Software Risk
It involve 2 characteristics
Uncertainty : Risk may or may not happen
Loss : If risk is reality unwanted loss or consequences will occur
It includes
1)Project Risk
2)Technical Risk
3)Business Risk
4)Known Risk
5)Unpredictable Risk
6) Predictable risk

Project risk: Threaten the project plan and affect schedule and resultant cost
Technical risk: Threaten the quality and timeliness of software to be produced
Business risk: Threaten the viability of software to be built
Known risk: These risks can be recovered from careful evaluation
Predictable risk: Risks are identified by past project experience
Unpredictable risk: Risks that occur and may be difficult to identify

Risk Identification
It concerned with identification of risk
Step1: Identify all possible risks
Step2: Create item check list
Step3: Categorize into risk components-Performance risk, cost risk, support
risk and
schedule risk
Step4: Divide the risk into one of 4 categories
Negligible-0
Marginal-1
Critical-2
Risk Identification
Risk Identification includes
 Product size
 Business impact
 Development environment
 Process definition
 Customer characteristics
 Technology to be built
 Staff size and experience

Risk Projection
Also called risk estimation. It estimates the impact of risk on the project and
the product.
Estimation is done by using Risk Table. Risk projection addresses risk in 2 ways

Risk Projection
Steps in Risk projection
1. Estimate Li for each risk
2. Estimate the consequence Xi
3. Estimate the impact
4. Draw the risk table
Ignore the risk where the management concern is low i.e., risk having impact
high or low with low probability of occurrence
Consider all risks where management concern is high i.e., high impact with
high or moderate probability of occurrence or low impact with high probability
of occurrence

Projection
The impact of each risk is assessed by Impact values
Catastrophic-1 Critical-2 Marginal-3 Negligible-4

Risk Refinement
Also called Risk assessment
Refines the risk table in reviewing the risk impact based on the following three
factors
a.Nature: Likely problems if risk occurs
b.Scope: Just how serious is it?
c.Timing: When and how long

It is based on Risk Elaboration

Calculate Risk exposure RE=P*C
Where P is probability and C is cost of project if risk occurs

Risk Mitigation Monitoring And Management (RMMM)

Its goal is to assist project team in developing a strategy for dealing with risk
There are three issues of RMMM
1) Risk Avoidance
2)Risk Monitoring and
3)Risk Management

Risk Mitigation Monitoring And Management (RMMM)

Risk Mitigation
Proactive planning for risk avoidance
Risk Monitoring
Assessing whether predicted risk occur or not
Ensuring risk aversion steps are being properly applied
Collection of information for future risk analysis
Determine which risks caused which problems
Risk Mitigation Monitoring And Management (RMMM)
Risk Management Contingency planning
Actions to be taken in the event that mitigation steps have failed and the risk
has become a live problem Devise RMMP(Risk Mitigation Monitoring And
Management Plan)

RMMM plan
It documents all work performed as a part of risk analysis.
Each risk is documented individually by using a Risk Information Sheet.
RIS is maintained by using a database system Quality Management

Quality Management: Quality concepts, Software quality assurance, Software

Reviews,
Formal technical reviews, Statistical Software quality Assurance, The Capability
Maturity
Model Integration (CMMI), Software reliability, The ISO 9000 quality standards.

CAPABILITY MATURITY MODEL INTEGRATION(CMMI)

• Developed by SEI(Software Engineering institute)
• Assess the process model followed by an organization and rate the
organization with different levels
• A set of software engineering capabilities should be present as organizations
reach different levels of
process capability and maturity.

CMMI process meta model can be represented in different ways

1.A continuous model
2.A staged model

Continuous model:
-Lets organization select specific improvement that best meet its business
objectives and minimize risk-
Levels are called capability levels.
-Describes a process in 2 dimensions
-Each process area is assessed against specific goals and practices and is rated
according to the following capability levels.

CMMI
• Six levels of CMMI
– Level 0:Incomplete
– Level 1:Performed
– Level 2:Managed
– Level 3:Defined
– Level 4:Quantitatively managed
– Level 5:Optimized

CMMI
• Incomplete -Process is adhoc . Objective and goal of process areas are not
known
• Performed -Goal, objective, work tasks, work products and other activities of
software process are
carried out
• Managed -Activities are monitored, reviewed, evaluated and controlled
• Defined -Activities are standardized, integrated and documented
• Quantitatively Managed -Metrics and indicators are available to measure the
process and quality
• Optimized - Continuous process improvement based on quantitative feed
back from the user
-Use of innovative ideas and techniques, statistical quality control and other
methods for process
improvement.

CMMI - Staged model

- This model is used if you have no clue of how to improve the process for
quality software.
- It gives a suggestion of what things other organizations have found helpful to
work first
- Levels are called maturity levels

Quality Concepts
Variation control is the heart of quality control
Form one project to another, we want to minimize the difference between the
predicted
resources needed to complete a project and the actual resources used,
including staff,
equipment, and calendar time
Quality of design
Refers to characteristics that designers specify for the end product Quality
Management

Quality of conformance
Degree to which design specifications are followed in manufacturing the
product

Quality control
Series of inspections, reviews, and tests used to ensure conformance of a work
product to its
specifications

Quality assurance
Consists of a set of auditing and reporting functions that assess the
effectiveness and
completeness of quality control activities.

Cost of Quality
Prevention costs
Quality planning, formal technical reviews, test equipment, training
Appraisal costs
In-process and inter-process inspection, equipment calibration and
maintenance, testing
Failure costs rework, repair, failure mode analysis
External failure costs
Complaint resolution, product return and replacement, help line support,
warranty work
Software Quality Assurance
Software quality assurance (SQA) is the concern of every software engineer to
reduce
cost and improve product time-to-market.
A Software Quality Assurance Plan is not merely another name for a test plan,
though
test plans are included in an SQA plan.
SQA activities are performed on every software project.
Use of metrics is an important part of developing a strategy to improve the
quality of
both software processes and work products.

Software Quality Assurance

Definition of Software Quality serves to emphasize:
Conformance to software requirements is the foundation from which software
quality is
measured.

Specified standards are used to define the development criteria that are used
to guide the
manner in which software is engineered.
Software must conform to implicit requirements (ease of use, maintainability,
reliability,
etc.) as well as its explicit requirements.

SQA Activities
Prepare SQA plan for the project.
Participate in the development of the project's software process description.
Review software engineering activities to verify compliance with the defined
software
process.
Audit designated software work products to verify compliance with those
defined as part
of the software process.
Ensure that any deviations in software or work products are documented and
handled
according to a documented procedure.
Record any evidence of noncompliance and reports them to management.

Software Reviews
Purpose is to find errors before they are passed on to another software
engineering
activity or released to the customer.
Software engineers (and others) conduct formal technical reviews (FTRs) for
software
quality assurance.
Using formal technical reviews (walkthroughs or inspections) is an effective
means for
improving software quality.

Formal Technical Review

A FTR is a software quality control activity performed by software engineers
and
others. The objectives are:
To uncover errors in function, logic or implementation for any representation
of the
software.
To verify that the software under review meets its requirements.
To ensure that the software has been represented according to predefined
standards.
To achieve software that is developed in a uniform manner and
To make projects more manageable.

Software Defects:
Industry studies suggest that design activities introduce 50-65% of all defects
or errors during the software process
Review techniques have been shown to be up to 75% effective in uncovering
design flaws which ultimately reduces the cost of
subsequent activities in the software process

Six Sigma for Software Engineering

The most widely used strategy for statistical quality assurance
Three core steps:
1. Define customer requirements, deliverables, and project goals via well-
defined
methods of customer communication.
2. Measure each existing process and its output to determine current quality
performance (e.g., compute defect metrics)
3. Analyze defect metrics and determine vital few causes.
For an existing process that needs improvement
1. Improve process by eliminating the root causes for defects
2. Control future work to ensure that future work does not reintroduce causes
of defects
If new processes are being developed
1. Design each new process to avoid root causes of defects and to meet
customer requirements
2. Verify that the process model will avoid defects and meet customer
requirements

Software Reliability
Defined as the probability of failure free operation of a
computer program in a specified environment for a specified
time period
Can be measured directly and estimated using historical and
developmental data
Software reliability problems can usually be traced back to
errors in design or implementation.
Measures of Reliability
Mean time between failure (MTBF) = MTTF + MTTR
MTTF = mean time to failure
MTTR = mean time to repair
Availability = [MTTF / (MTTF + MTTR)] x 100%

ISO 9000 Quality Standards

ISO (International Standards Organization) is a group or consortium of 63
countries
established to plan and fosters standardization. ISO declared its 9000 series of
standards in
1987. It serves as a reference for the contract between independent parties.
The ISO 9000
standard determines the guidelines for maintaining a quality system. The ISO
standard
mainly addresses operational methods and organizational methods such as
responsibilities,
reporting, etc. ISO 9000 defines a set of guidelines for the production process
and is not
directly concerned about the product itself.

1. ISO 9001: This standard applies to the organizations engaged in design,

development,
production, and servicing of goods. This is the standard that applies to most
software
development organizations.
2. ISO 9002: This standard applies to those organizations which do not design
products but
are only involved in the production. Examples of these category industries
contain steel and
car manufacturing industries that buy the product and plants designs from
external sources
and are engaged in only manufacturing those products. Therefore, ISO 9002
does not apply
to software development organizations.
3. ISO 9003: This standard applies to organizations that are involved only in the
installation
and testing of the products. For example, Gas companies.
An organization determines to obtain ISO 9000 certification applies to ISO
registrar office for
registration. The process consists of the following stages:

1. Application: Once an organization decided to go for ISO certification, it

applies to the registrar for
registration.
2. Pre-Assessment: During this stage, the registrar makes a rough assessment
of the organization.
3. Document review and Adequacy of Audit: During this stage, the registrar
reviews the document
submitted by the organization and suggest an improvement.
4. Compliance Audit: During this stage, the registrar checks whether the
organization has compiled the
suggestion made by it during the review or not.
5. Registration: The Registrar awards the ISO certification after the successful
completion of all the
phases.
6. Continued Inspection: The registrar continued to monitor the organization
time by time.