merged_notes_unit_1_2_3.pdf

M.K. Institute of Computer Studies SE-I (Sem-3)
Prepared By: Nidhi Solanki (Assist. Prof.) Page 1
UNIT-1:INTRODUCTION
1.1 What is software?
1.2 software engineering: definition
1.3 software characteristics

SOFTWARE:
Software can be defined as:
(1) Instructions (computer programs) that when executed provide desired function
and performance,
(2) Data structures that enable the programs to effectively control data,
(3) Documents that describes the operations and uses of the software.
SOFTWARE ENGINEERING:
Software is a collection of programs, associated libraries and documentations,
which are developed for a specific purpose.
Engineering on the other hand, is all about developing products, using well defined,
scientific principles and methods.
Definition of Software Engineering:
1) IEEE defines software engineering as:
Software Engineering is the application of a organized, controlled,
quantifiable (scientific, with measurements and calculations) approach to the development,
operation and maintenance of software; that is, the application of engineering to software.
2) Fritz Bauer, a German computer scientist, defines software engineering as:
Software engineering is the use of sound engineering principles in order to
obtain economically software that is reliable and work efficiently on real machines.

SOFTWARE CHARACTERISTICS:
1. Software is developed or engineered; it is not manufactured in the
classical sense.
There are some similarities between software development and hardware manufacture;
but the two activities are fundamentally different.
In both activities, high quality is achieved by good design, but in manufacturing phase for
hardware we get more quality problems as compare to software. In software quality can
be easily achieved and corrected through various software quality techniques.
Both activities are dependent on people, but the relationship between people and work
is entirely different .
Both activities require the construction of a product but the methods of construction
are different.
Management of software projects and manufacturing projects is different.
2. Software doesn't wear out.
Software does not wear out. Software is not affected by the environmental maladies like
the affects of dust, vibration, misuse, and temperature limits etc. but it may be deteriorated due to
continuous demand of user for chance. To understand this let us consider the life cycle of software.
Life cycle of software:
Software shows high failure rate in its early state. Then it gets into changes and the
defects get corrected and thus it comes to the idealized state.
Software may get the need of modification as the users demand for the software
change. And when it occurs, the unfulfilled demands will be considered as defects and
thus the failure rate will increase.

Another new modification from user side may come again. In that way, slowly, the minimum
failure rate level begins to rise which will cause the software deteriorated due to change,
but it does not “wear out”.
figure 1.2, shows the curve for software. When some new defects will get introduced,
causing the failure rate curve to spike as shown in Figure 1.2. Before the curve can return to
the original steady-state failure rate, another change is requested, causing the curve to
spike again. Slowly, the failure rate begins to rise.
FIGURE 1.2
Life cycle of hardware:
At the beginning of the life of hardware it shows high failure rate as it contains many
defects. It is shown in the given figure 1.1, which is also known as the “Bathtub Curve”.
By time, the manufacturers or the designers repair these defects and it becomes ok. But
after that, as time passes, the failure rate rises again and this may be caused by excessive
temperature, dust, vibration, improper use and so on and at one time it becomes totally
unusable.

This state is the “wear out” state.
When a hardware component wears out, it is replaced by a spare part. There are no software
spare parts. Every software failure indicates an error in design or in the process. Therefore,
software maintenance involves considerably more complexity than hardware maintenance.
3. Although the industry is moving toward component-based assembly, most
software continues to be custom built.
Component-based software engineering (CBSE) is a reuse-based approach to define,
implement and connect different components of software for making of a software product.
A system is divided into various processes (components). Each component has its own
related set of data and functions inside it. Components are also known as module.
Reusability is an important characteristic of a high-quality software component.
Programmers should design and implement software components in such a way that many
different programs can reuse them.

Reusability is the use of existing resources in some form within the software product
development process; these resources are products and by-products of the software
development life cycle and include program codes, software components, test cases,
designs and documentation.
But sometimes reusable components do not fulfill the requirement. Because of complexity of
code we could not be able to do changes to the system, given by the customer , which is not
suitable so instead of this we can create a custom built software.
Since custom software is developed for a single customer it can be change with less
complexity and fulfills customer's expectations. Custom built software does not follows
reuseability.
A great advantage of custom software development is that it can be built perfectly to fit your
environment to solve your problem in the way you want it.
For example, you can get a nice simple interface which other people are using with a lot of
detailed steps. By reducing the number of options in the interface you can greatly reduce the
chances of errors.

UNIT 2-SOFTWARE ENGINEERING
2.1 Software Applications, Myths
2.2 Software Engineering: Generic View

APPLICATIONS OF SOFTWARE:
The various applications of software are:
1) System software:
System software is a collection of programs written to service other programs. System
software is a type of computer program that is designed to run a computer’s hardware
and application programs. The system software is the interface between the hardware and
user applications.
Example: compilers, editors, and file management Utilities, operating system components,
drivers, telecommunications processors.
2) Real-time software:
Software that controls real-world events as they occur is called real time.
Elements of real-time software include a data-gathering component that collects and formats
information from an external environment, an analysis component that transforms
information as required by the application, a control/output component that responds to the
external environment, and a monitoring component that coordinates all other components so
that real-time response can be maintained.
3) Business software:
Business software is software that is used for business purposes. The term is often used
more specifically for software that helps a business to accomplish specific goals. Business
information processing is the largest single software application area.
Example: MIS, DSS, ERP, and CRM.
4) Engineering and scientific software:
The software which is used in Engineering and scientific area is called Engineering and
scientific software. Engineering and scientific software have been characterized by number
crunching algorithms.
Applications: astronomy, volcanology, automotive stress analysis, space shuttle orbital
dynamics, molecular biology, automated manufacturing, Computer-aided design, system
simulation.

5) Embedded software.
Embedded software is computer software, written to control machines or devices that are not
typically thought of as computers.
Manufacturers 'build in' embedded software in the electronics in cars, telephones,
modems, robots, appliances, toys, security systems, televisions and set-top boxes,
and digital watches etc.
Embedded software resides in read-only memory and is used to control products and
systems for the consumer and industrial markets. Embedded software can perform very
limited functions.
Example: keypad control for a microwave oven, digital functions in an automobile such as
fuel control, and braking systems.
6) Personal computer software:
A personal computer (PC) is a general-purpose computer whose size, capabilities, and
original sale price make it useful for individuals, and is intended to be operated directly by
an end-user.
Example: Word processing, spreadsheets, computer graphics,
Multimedia, entertainment, database management, personal and business financial
Applications, external network, and database access.
7) Web-based software:
Web based software, (or a web-based application) is software that runs on a server
(computer connected to the Internet), while users connect to it from their computers using an
Internet browser.
Example: web mail, social networking sites and online shoping.
8) Artificial intelligence software:
Artificial intelligence (AI) is an area of computer science that emphasizes the creation of
intelligent machines that work and reacts like humans. The software which is used for
Artificial intelligence (AI) area is called Artificial intelligence software. Some of the activities
computers with artificial intelligence are designed for include:
a) Speech recognition

b) Learning
c) Planning
d) Problem solving
Artificial intelligence (AI) software makes use of non-numerical algorithms to solve complex
problems that are not open to computation or straightforward analysis.
Example: Expert systems, also called knowledgebase systems, pattern recognition (image
and voice), artificial neural networks, theorem proving, and game playing are representative
of applications within this category.
SOFTWARE MYTHS
Software myths are the illusions which results into software development problems. There are
many software myths that are still believe but it is actually untrue. The categories of software
myths are as follows:
1. MANAGEMENT MYTH
2. CUSTOMER MYTH
3. PRACTITIONER MYTH
1) MANAGEMENT MYTHS:
Managers with software responsibility are under pressure to maintain budgets, schedules,
And improve quality. They have following myths:
1) MYTH: We already have a book that's full of standards and procedures for building
Software, it will provide my people everything, they need to know?
REALITY: The book of standards may very well exist, but some features must be notice as:
• Is it used?
• Are software practitioners aware of its existence?
• Does it include modern software engineering techniques?
• Is it complete?
• Is it focuses on quality?
In many cases, the answer to all of these questions is no.

2) MYTH: My people have modern software development tools; after all, we buy them the
newest computers.
REALITY:
• It takes much more than the latest model mainframe, workstation, or PC to do high-quality
software development.
• Computer-aided software engineering (CASE) tools are more important than hardware for
achieving good quality and productivity; still the majority of software developers do not use
them effectively.
3) MYTH: If we are getting late in software supply, we can add more programmers and
manage it.
REALITY:
• Software development is not a mechanistic process like manufacturing., as new people
are added, training must be given to them.
• For reducing the amount of time in software development. People can be added but only in
a planned and well-coordinated manner.
4) MYTH: If I decide to outsource the software project to a third party, I can just relax
and let that firm build it.
REALITY:
• If third party does not understand completely, the requirements of software projects, it will
not result in a good software product.
• For the development of good quality software, time to time meeting with user is required to
know customer’s expectations with software.
• Customer is linked with management not with third party directly.
• So management cannot just relax after outsourcing of software.

2) CUSTOMER MYTHS:
A customer who requests computer software has several myths, which doesn’t result in good
software development. Myths lead to false software and dissatisfaction with the developer. The
customer myths are as follows:
1) MYTH: A general statement of objectives is enough to start writing programs—
we can fill in the details afterward.
REALITY:
• A poor definition is the main reason of failed software.
• A formal and detailed description of the information of software domain, function, behavior,
performance, interfaces, design constraints, and validation criteria is essential.
• These characteristics can be determined only after communication between customer
and developer.
2) MYTH: Project requirements normally change, but change can be easily adjusted
because software is flexible.
REALITY:
• It is true that software requirements may change, but the impact of change
varies with the time at which it is given.
• When required changes are given in early stage of software development, cost impact is
relatively small but as time increases cost grows fastly.
• The following figure 1.3 shows the impact of change in the software development process.
When change is given during definition phase, cost of change will be minimum. If change
is given during development phase cost will be increases. If change is given after release
of software then cost of change will be very high.

2) PRACTITIONER'S MYTHS:
Myths that are still believed by software practitioners are as follows:
1) MYTH: Once we make the program and get it to work, our job is finished.
REALITY:
• 60 to 80 percent of efforts for software are required, after its delivery to the customer for
the first time.
• Practitioner cannot be just relaxed after giving software to customer.
• If customer is not satisfied and demand for the change, practitioners have to work for that
change.
2) MYTH: Until I get the program running I have no way of finding its quality.
REALITY:
• Software quality can be found before running program also.
• There are many ‘software quality assurance’ mechanisms, which helps in finding quality of
software.
• The formal technical review of software helps in checking the quality of software.

3) MYTH: The only deliverable work product for a successful project is the working
program.
REALITY:
• A working program is only one part of software.
• Documentation provides information and guidance for operating software and to know
more about it.
• With working program a good interface, documentation and a small training to customer is
required.
3) MYTH: The life cycle of software engineering requires creation of big and unnecessary
documentation and will regularly slow us down .
REALITY:
• For good quality software documentation is to be prepared after every stage, so that
developer of next stage can understand the software better.
• Without documentation software development is incomplete. It is required to know more
about software.
GENERIC VIEW OF SOFTWARE ENGINEERING:
Engineering is the analysis, design, construction, verification, and management of technical (or
social) entities. Software engineer should consider the generic view of the software process
effectively.
There are three generic phases associated with software engineering:
1) DEFINITION PHASE
2) DEVELOPMENT PHASE
3) SUPPORT PHASE

1. THE DEFINITION PHASE:
The definition phase focuses on what. During this phase the software engineer attempts to
identify:
1. What information is to be processed,
2. What function and performance are desired,
3. What system behavior can be expected,
4. What interfaces are to be established,
5. What design constraints exist, and
6. What validation criteria are required to define a successful system?
The key requirements of the system and the software are identified. The methods applied
during the definition phase will vary depending on the software engineering paradigm that is
applied.
DEFINITION PHASE DEVELOPMENT
PHASE
SUPPORT PHASE
CORRECTION
ADAPTATION
ENHANCEMENT
PREVENTION

Three major tasks will occur in some form:
a. System or information engineering,
b. Software project planning, and
c. Requirements analysis
2. THE DEVELOPMENT PHASE:
The development phase focuses on how. During development a software engineer attempts
to define:
1. How data are to be structured,
2. How function is to be implemented within a software architecture,
3. How procedural details are to be implemented,
4. How interfaces are to be characterized,
5. How the design will be translated into a programming language (or Nonprocedural
language), and
6. How testing will be performed.
The methods applied during the development phase will vary, but three specific technical tasks
should always occur:
a. Software design,
b. Code generation, and
c. Software testing.
3. THE SUPPORT PHASE:
The support phase focuses on change. Four types of change are encountered during the
support phase:
1) Correction:
Customer will uncover defects in the software. Corrective maintenance changes the
software to correct defects.
2) Adaptation:
Over time, the original environment (e.g., CPU, operating system, business rules, external
product characteristics) for which the software was developed is likely to change.

Adaptive maintenance results in modification to the software to accommodate changes
to its external environment
3) Enhancement:
As software is used, the customer/user will recognize additional functions that will provide
benefit.
Perfective maintenance extends the software beyond its original functional
requirements.
4) Prevention:
Computer software deteriorates due to change, and because of this, preventive
maintenance, often called software reengineering, and must be conducted to enable the
software to serve the needs of its end users.
UMBRELLA ACTIVITIES:
The phases in our generic view of software engineering are balanced by a number of umbrella
activities. Umbrella activities are applied throughout the software process.
Typical activities in this category include:
1). Software project tracking and control
When plan, tasks, models all have been done then a set of software engineering tasks that will
enable to get the software development job done on time will have to be created.
It provides assessing progress against the project plan and takes sufficient action to maintain
schedule.
2). Formal technical reviews
This includes reviewing the techniques that has been used in the project, whether they are
correct or not.
It helps in assessing software work products in an effort to uncover and remove errors before
goes into next action or activity.

3). Software quality assurance
This is very important to ensure the quality of each part to ensure the total quality of the system.
It defines and conducts the activities required to ensure software quality.
4). Software configuration management
Software configuration management (SCM) is a set of activities designed to control change by
identifying the work products that are likely to change, establishing relationships among them,
defining process for them.
It manages the effects of change
5). Document preparation and production
All the project planning and other activities should be specified in a proper document.
It Help to create work products such as models, documents, logs, form and list.
6). Reusability management
This includes the backing up of each part of the software project they can be corrected or any
kind of support can be given to them later to update or upgrade the software at user/time
demand.
It defines criteria for work product reuse and Mechanisms to achieve reusable components.
7). Measurement
This will include all the measurement of every aspects of the software project.
It measures number of process, project, people, cost, efforts, schedule, errors, defects, various
condition.
8). Risk management
Risk management finds solves risks that may affect the output quality of software.
Risk management is a series of steps that help a software team to understand and manage
uncertainty.
It’s a really good idea to identify it, assess its chances of occurrence, estimate its result, and
establish a proper plan.

UNIT 3- SOFTWARE PROCESS MODELS
3.1 Introduction of Waterfall Model.
3.2 Prototype Model.
3.3 Spiral Model
3.4 Incremental Model

SOFTWARE PROCESS MODELS
To solve actual problems in an industry, a software engineer or a team of engineers
must add a ‘development strategy’ that should include the information about Process, Methods,
Tools, Layers and the Generic phases of software.
This strategy is often referred to as a process model or a software engineering paradigm.
3.1 - WATERFALL MODEL
The Waterfall Model was first Process Model to be introduced.
It is also called as a linear-sequential life cycle model because it shows the software
development process in a linear sequential flow.
In a waterfall model, each phase must be completed before the next phase can begin and
there is no overlapping in the phases.
Waterfall model is the earliest SDLC approach that was used for software development.
It is very simple to understand and use.
In The Waterfall approach, the whole process of software development is divided into
separate phases.
In Waterfall model, the outcome of one phase acts as the input for the next phase
sequentially.
Following is a diagrammatic representation of different phases of waterfall model.

The sequential phases in Waterfall model are:
1) Requirement Gathering and Analysis:
All possible requirements of the system to be developed are captured in this phase and
documented in requirement specification documentation.
2) System Design:
The requirement specifications from first phase are studied in this phase and system
design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.
3) Implementation:
With inputs from system design, the system is first developed in small programs called
units, which are integrated in the next phase. Each unit is developed and tested for its
functionality, which is referred to as Unit Testing.
4) Integration and Testing:
All the units developed in the implementation phase are integrated into a system after
testing of each unit. Post integration the entire system is tested for any faults and
failures.

5) Deployment of system:
Once the functional and non-functional testing is done, the product is deployed in the
customer environment or released into the market.
6) Maintenance:
There are some issues, which come up in the client environment. To fix those issues
maintenance is done. Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.
WATERFALL MODEL APPLICATIONS
Some situations where the use of Waterfall model is most appropriate are:
1. Requirements are very well documented, clear and fixed.
2. Product definition is stable (no change).
3. Technology is understood and is not dynamic.
4. There are no ambiguous requirements (no double meaning and confusion).
5. Ample resources with required expertise are available to support the product.
6. The project is short.
ADVANTAGES OF WATERFALL MODEL

Simple and easy to understand and use.

Easy to manage due to the rigidity (strictness) of the model. Each phase has specific
deliverables (output) and a review process.

Phases are processed and completed one at a time.

Works well for smaller projects where requirements are very well understood.

Clearly defined stages.

Well understood milestones (objective or target).

Easy to arrange tasks.


Process and results are well document.
DISADVANTAGES OF WATERFALL MODEL

No working software is produced until late during the life cycle.

High amounts of risk and uncertainty.

Not a good model for complex and object-oriented projects.

Poor model for long and ongoing projects.

It is difficult to measure progress within stages.

Cannot accommodate changing requirements.

No working software is produced until late in the life cycle.

Adjusting scope during the life cycle can end a project.

Integration is done as a big-bang. At the very end, this doesn’t allow identifying any
technological or business problem or challenges early.
3.2 - PROTOTYPE MODEL
A process model for software engineering is chosen based on the nature of the project
application, the methods and tools to be used. The prototype model looks like as follows:


The prototyping paradigm as in given figure begins with requirements gathering.

Developer and customer meet and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is required.

A quick design then occurs.

The quick design focuses on a representation of those aspects of the software that will
be visible to the customer/user (e.g., input approaches and output formats).

The quick design leads to the construction of a prototype.

The prototype is evaluated by the customer/user and used to refine requirements for the
software to be developed.

Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at
the same time enabling the developer to better understand what needs to be done.

Ideally, the prototype serves as a mechanism for identifying software requirements.

If a working prototype is built, the developer attempts to use existing program fragments
or applies tools (e.g., report generators, window managers) that enable working
programs to be generated quickly.
ADVANTAGES OF PROTOTYPE MODEL:
1) Users are actively involved in the development
2) Since in this methodology a working model of the system is provided, the users get a
better understanding of the system being developed.
3) Errors can be detected much earlier.
4) Quicker user feedback is available leading to better solutions.
5) Missing functionality can be identified easily
6) Problematic functions can be identified.

Disadvantages of Prototype model:
1) Leads to implementing and then repairing by-product again and again.
2) Practically, this methodology may increase the complexity of the system.
3) Incomplete application may cause problem in design and analysis.
4) The developer often makes implementation compromises in order to get a prototype
working quickly, which results in inappropriate operating system, programming
language, algorithms usage because it is available and known, which results in
inefficiency.
WHEN TO USE PROTOTYPE MODEL:

Prototype model should be used when, the desired system, needs to have a lot of
interaction with the end users.

Typically, online systems, web interfaces have a very high amount of interaction with end
users, are best suited for Prototype model.

Prototyping ensures that the end users always work with the system and provide
a feedback which is included in the prototype to result in a useable system. They are
excellent for designing good human computer interface systems.
COMPARISON BETWEEN PROTOTYPING AND WATERFALL
SIMILARITIES
1. Each lifecycle is divided into phases where specific objectives are to be met.
2. Both models have an objective to reduce the development and maintenance cost.
3. Both models are suitable for short-term program or short-life span system.

DISSIMILARITIES
S.NO: WATERFALL MODEL PROTOTYPE MODEL
1. Client can only preview the system only
after the final version of the software is
developed because there is no feedback
loop.
Clients have a preview of the system
from the quick design and the
prototype developed early at the
process.
2. Developers encounter a freezing (fix)
requirement.
Developers can refine or add
requirements and specification to the
system.
3. The complexity of software increases
because of the nature of the model; each
phase is sequential of the other.
The complexity of software is low
because the prototype enables the
developer to detect any deficiency
early at the process.
4. Chance of error is more. Chance of error is less.
3.3 SPIRAL MODEL

Boehm firstly proposed the spiral model.

It has the iterative nature of prototyping model and the systematic nature of the waterfall
model.

It provides the rapid development of the software.

During early iterations, the incremental release might be a paper model or prototype.

During later iterations, increasingly more complete versions of the engineered system are
produced.

A spiral model is divided into a number of framework activities, also called task regions.


Given figure depicts a Spiral model that contains six task regions:
1) Customer communication—
It includes collection of tasks, required for establishing effective communication between
developer and customer. Series of meeting and interview are conducted between
customer and developer
2) Planning—
It includes collection of tasks required for planning about resources (hardware, software,
tools, people), timelines (schedule for different activities of software development), and
other project related information.
3) Risk analysis—
It includes collection of tasks required to judge both technical and management risks.
4) Engineering—
It includes collection of tasks required for building one or more representations of the
application.
5) Construction and release—
It includes collection of tasks required for constructing, testing, installing, and providing
user support (e.g., documentation and training).
6) Customer evaluation—
It includes collection of tasks required for obtaining customer feedback based on
evaluation of the software representations done by the user.


Each of the regions includes a set of tasks, called a task set, that are chosen according
to the project to be undertaken.

For small projects, the number of work tasks is low.

For larger and critical projects, the number of work tasks is more.

In all work tasks, the umbrella activities are applied.

As this evolutionary process begins, the software engineering team moves around
the spiral(curve) in a clockwise direction, beginning at the center.

The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop a prototype
and then progressively more sophisticated versions of the software.

Cost, schedule, number of iterations required for completing the software, and functions
are adjusted based on feedback taken from customer evaluation.
ADVANTAGES OF SPIRAL MODEL:
1) Avoidance of risk due to good Risk Analysis.
2) Good for large and critical projects.
3) It provides strong approval and documentation control.
4) Additional Functionality can be added at a later date.
5) Software is produced early in the software life cycle.
DISADVANTAGES OF SPIRAL MODEL:
1) Can be a costly model to use.
2) Risk analysis requires highly specific expertise.
3) Project’s success is highly dependent on the risk analysis phase.
4) Doesn’t work well for smaller projects.

WHEN TO USE SPIRAL MODEL:
1) When costs and risk estimation is important.
2) For medium to high-risk projects
3) Users are unsure of their needs.
4) Requirements are complex.
5) For new product.
6) When major changes are expected.
3.4 INCREMENTAL MODEL
The incremental model combines elements of the waterfall model with the iterative idea
of prototyping.

The product is decomposed into a number of components, each of which is designed
and built separately (termed as builds).

In this model, each component (module) passes through the requirements, design,
implementation and testing phases.

Each component is delivered to the client when it is complete.

This allows partial use of the product and avoids a long development time. It also avoids
long waiting period.

The incremental model applies the waterfall model incrementally.

The series of releases is referred to as “increments”, with each increment providing more
functionality to the customers.

The Incremental Model is as follows:

In the first iteration the first module of the project is totally ready and can be given to the
customers for evaluation. Based on customer feedback, a plan is developed for the next
iteration, and modifications are made accordingly.

Likewise in the second iteration the other module is ready and integrated with the first
module. Similarly, in the third iteration the whole product is ready and integrated. Hence,
the product got ready step by step.

This process continues, with increments being delivered until the complete product is
delivered.
ADVANTAGES OF INCREMENTAL MODEL:
1. Generates working software quickly.
2. This model is more flexible – less costly to change scope and requirements.
3. It is easier to test and debug during a smaller iteration.

4. In this model customer can respond to each built.
5. Lowers initial delivery cost.
6. Easier to manage risk because risky pieces are identified and handled during it’s
iteration.
DISADVANTAGES OF INCREMENTAL MODEL:
1. Needs good planning and design.
2. Needs a clear and complete definition of the whole system before it can be broken down
and built incrementally.
3. Total cost is higher than waterfall.
WHEN TO USE THE INCREMENTAL MODEL:
1. This model can be used when the requirements of the complete system are clearly
defined and understood.
2. There is a need to get a product to the market early.
3. A new technology is being used.
4. Resources are not available.
5. There are some high-risk features.

merged_notes_unit_1_2_3.pdf

More Related Content

What's hot

Similar to merged_notes_unit_1_2_3.pdf

Recently uploaded

merged_notes_unit_1_2_3.pdf