1.

Introduction to Software Engineering and Process Models

1.1 NATURE of SOFTWARE

Today, software takes on a dual role. It is a product, and at the same time, the vehicle for delivering a
product. As a product, it delivers the computing potential embodied by computer hardware or more broadly,
by a network of computers that are accessible by local hardware. Whether it resides within a mobile phone
or operates inside a mainframe computer, software is information transformer— producing, managing,
acquiring, modifying, displaying, or transmitting information that can be as simple as a single bit or as
complex as a multimedia presentation derived from data acquired from dozens of independent sources. As a
vehicle used to deliver the product, software acts as the basis for the control of the computer (operating
systems), the communication of information (networks), and the creation and control of other
programs (software tools and environments).
Software delivers the most important product of our time—information. It transforms personal data (e.g., an
individual’s financial transactions) so that the data can be more useful in a local context; it manages business
information to enhance competitiveness; it provides a gateway to worldwide information networks (e.g., the
Internet), and provides the means for acquiring information in all of its forms.
The role of computer software has undergone significant change over the last half-century. Dramatic
improvements in hardware performance, profound changes in computing architectures, vast increases in
memory and storage capacity, and a wide variety of exotic input and output options, have all precipitated
more sophisticated and complex computer-based systems. Sophistication and complexity can produce
dazzling results when a system succeeds, but they can also pose huge problems for those who must build
complex systems.
Today, a huge software industry has become a dominant factor in the economies of the industrialized world.
Teams of software specialists, each focusing on one part of the technology required to deliver a complex
application, have replaced the lone programmer of an earlier era.

Software is:
(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.
Software Application Domains
Today, seven broad categories of computer software present continuing challenges for software engineers:
System software- it is a collection of programs written to service other programs. Some system software
(e.g., compilers, editors, and file management utilities) processes complex, but determinate,4 information
structures. Other systems applications (e.g., operating system components, drivers, networking software,
telecommunications processors) process largely indeterminate data.
In either case, the systems software area is characterized by heavy interaction with computer hardware;
heavy usage by multiple users; concurrent operation that requires scheduling, resource sharing, and
sophisticated process management; complex data structures; and multiple external interfaces.
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.
In addition to conventional data processing applications, application software is used to control business
functions in real time (e.g., point-of-sale transaction processing, real-time manufacturing process control).
Engineering/scientific software- has 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. However, modern applications within the
engineering/scientific area are moving away from conventional numerical algorithms. Computer-aided
design, system simulation, and other interactive applications have begun to take on real-time and even
system software characteristics.
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. Embedded software can perform limited and esoteric
functions (e.g., key pad control for a microwave oven) or provide significant function and control capability
(e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems).
Product-line software- is designed to provide a specific capability for use by many different customers.
Product-line software can focus on a limited and esoteric marketplace (e.g., inventory control products) or
address mass consumer markets (e.g., word processing, spreadsheets, computer graphics, multimedia,
entertainment, database management, and personal and business financial applications).
Web applications- are 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. However, as Web 2.0 emerges, WebApps are evolving
into sophisticated computing environments that not only provide stand-alone features, computing functions,
and content to the end user, but also are integrated with corporate databases and business applications.
Artificial intelligence software- makes use of non-numerical 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.
Millions of software engineers worldwide are hard at work on software projects in one or more of these
categories. In some cases, new systems are being built, but in many others, existing applications are being
corrected, adapted, and enhanced.

Some new challenges have also appeared on the horizon:

Open-world computing- the rapid growth of wireless networking may soon lead to true pervasive,
distributed computing. The challenge for software engineers will be to develop systems and application
software that will allow mobile devices, personal computers, and enterprise systems to communicate across
vast networks.
Net-sourcing- the World Wide Web is rapidly becoming a computing engine as well as a content provider.
The challenge for software engineers is to architect simple (e.g., personal financial planning) and
sophisticated applications that provide a benefit to targeted end-user markets worldwide.
Open source- a growing trend that results in distribution of source code for systems applications (e.g.,
operating systems, database, and development environments) so that many people can contribute to its
development. The challenge for software engineers is to build source code that is self-descriptive, but more
importantly, to develop techniques that will enable both customers and developers to know what changes
have been made and how those changes manifest themselves within the software.
Software Engineering
In order to build software that is ready to meet the challenges of the twenty-first century, you must recognize
a few simple realities:
• A concerted effort should be made to understand the problem before a software solution is
developed.
• Design becomes a pivotal activity.
• Software should exhibit high quality.
• Software should be maintainable.

These simple realities lead to one conclusion: software in all of its forms and across all of its application
domains should be engineered. And that leads to the - software engineering.
A definition proposed by Fritz Bauer:
Software engineering is the establishment and use of sound engineering principles in order to obtain
economically software that is reliable and works efficiently on real machines.

The IEEE has developed a more comprehensive definition when it states:

Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering to software. (2)
The study of approaches as in (1).

Software engineering is a layered technology as shown in figure,

Referring to figure, any engineering approach (including software engineering) must rest on an
organizational commitment to quality. Total quality management, Six Sigma, and similar philosophies foster
a continuous process improvement culture, and it is this culture that ultimately leads to the development of
increasingly more effective approaches to software engineering. The bedrock that supports software
engineering is a quality focus.
The foundation for software engineering is the process layer. The software engineering process is the glue
that holds the technology layers together and enables rational and timely development of computer software.
Process defines a framework that must be established for effective delivery of software engineering
technology.
The software process forms the basis for management control of software projects and establishes the
context in which technical methods are applied, work products (models, documents, data, reports, forms,
etc.) are produced, milestones are established, quality is ensured, and change is properly managed.
Software engineering methods provide the technical how-to’s for building software. Methods encompass a
broad array of tasks that include communication, requirements analysis, design modeling, program
construction, testing, and support. Software engineering methods rely on a set of basic principles that govern
each area of the technology and include modeling activities and other descriptive techniques.
Software engineering tools provide automated or semi-automated support for the process and the methods.
When tools are integrated so that information created by one tool can be used by another, a system for the
support of software development, called computer-aided software engineering, is established.

Software Process
A process is a collection of activities, actions, and tasks that are performed when some work product is to be
created. An activity strives to achieve a broad objective (e.g., communication with stakeholders) and is
applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor
with which software engineering is to be applied. An action (e.g., architectural design) encompasses a set of
tasks that produce a major work product (e.g., an architectural design model). A task focuses on a small, but
well-defined objective (e.g., conducting a unit test) that produces a tangible outcome.
In the context of software engineering, a process is not a rigid prescription for how to build computer
software. Rather, it is an adaptable approach that enables the people doing the work (the software team) to
pick and choose the appropriate set of work actions and tasks. The intent is always to deliver software in a
timely manner and with sufficient quality to satisfy those who have sponsored its creation and those who
will use it.

A process framework establishes the foundation for a complete software engineering process by identifying
a small number of framework activities that are applicable to all software projects, regardless of their size or
complexity. In addition, the process framework encompasses a set of umbrella activities that are applicable
across the entire software process.
A generic process framework for software engineering encompasses five activities:
i. Communication- Before any technical work can commence, it is critically important to communicate and
collaborate with the customer (and other stakeholders). The intent is to understand stakeholders’ objectives
for the project and to gather requirements that help define software features and functions.
ii. Planning- Any complicated journey can be simplified if a map exists. A software project is a complicated
journey, and the planning activity creates a “map” that helps guide the team as it makes the journey. The
map—called a software project plan—defines the software engineering work by describing the technical
tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be
produced, and a work schedule.
iii. Modeling- Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a carpenter, or an
architect, you work with models every day. You create a “sketch” of the thing so that you’ll understand the
big picture—what it will look like architecturally, how the constituent parts fit together, and many other
characteristics. If required, you refine the sketch into greater and greater detail in an effort to better
understand the problem and how you’re going to solve it. A software engineer does the same thing by
creating models to better understand software requirements and the design that will achieve those
requirements.
iv. Construction- This activity combines code generation (either manual or automated) and the testing that
is required to uncover errors in the code.
v. Deployment- The software (as a complete entity or as a partially completed increment) is delivered to the
customer who evaluates the delivered product and provides feedback based on the evaluation.

These five generic framework activities can be used during the development of small, simple programs, the
creation of large Web applications, and for the engineering of large, complex computer-based systems. The
details of the software process will be quite different in each case, but the framework activities remain the
same.
For many software projects, framework activities are applied iteratively as a project progresses. That is,
communication, planning, modeling, construction, and deployment are applied repeatedly through a
number of project iterations. Each project iteration produces a software increment that provides stakeholders
with a subset of overall software features and functionality. As each increment is produced, the software
becomes more and more complete.

Software engineering process framework activities are complemented by a number of umbrella activities. In
general, umbrella activities are applied throughout a software project and help a software team manage and
control progress, quality, change, and risk.
Typical umbrella activities include:
Software project tracking and control- allows the software team to assess progress against the project plan
and take any necessary action to maintain the schedule.
Risk management- assesses risks that may affect the outcome of the project or the quality of the product.
Software quality assurance- defines and conducts the activities required to ensure software quality.
Technical reviews- assess software engineering work products in an effort to uncover and remove errors
before they are propagated to the next activity.
Measurement- defines and collects process, project, and product measures that assist the team in delivering
software that meets stakeholders’ needs; can be used in conjunction with all other framework and umbrella
activities.
Software configuration management- manages the effects of change throughout the software process.
Reusability management- defines criteria for work product reuse (including software components) and
establishes mechanisms to achieve reusable components.
Work product preparation and production- encompasses the activities required to create work products
such as models, documents, logs, forms, and lists.

CAPABILITY MATURITY MODEL (CMM)

A maturity model is applied within the context of an SPI framework. The intent of the maturity model is to
provide an overall indication of the “process maturity” exhibited by a software organization. That is, an
indication of the quality of the software process, the degree to which practitioner’s understand and apply the
process, and the general state of software engineering practice. This is accomplished using some type of
ordinal scale.
For example, the Software Engineering Institute’s Capability Maturity Model suggests five levels of
maturity:
Level 5, Optimized- The organization has quantitative feedback systems in place to identify process
weaknesses and strengthen them pro-actively. Project teams analyze defects to determine their causes;
software processes are evaluated and updated to prevent known types of defects from recurring.
Level 4, Managed- Detailed software process and product quality metrics establish the quantitative
evaluation foundation. Meaningful variations in process performance can be distinguished from random
noise, and trends in process and product qualities can be predicted.
Level 3, Defined-Processes for management and engineering are documented, standardized, and integrated
into a standard software process for the organization. All projects use an approved, tailored version of the
organization’s standard software process for developing software.
Level 2, Repeatable-Basic project management processes are established to track cost, schedule, and
functionality. Planning and managing new products is based on experience with similar projects.
Level 1, Initial—Few processes are defined, and success depends more on individual heroic efforts than on
following a process and using a synergistic team effort.

1.2 PROCESS MODELS

A process is 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.
The software process is represented schematically in Figure. Referring to the figure, each framework activity
is populated by a set of software engineering actions. Each software engineering action is defined by a task
set that identifies the work tasks that are to be completed, the work products that will be produced, the
quality assurance points that will be required, and the milestones that will be used to indicate progress.

A generic process framework for software engineering defines five framework activities—communication,
planning, modeling, construction, and deployment. In addition, a set of umbrella activities—project
tracking and control, risk management, quality assurance, configuration management, technical reviews, and
others—are applied throughout the process. Process flow—describes how the framework activities and the
actions and tasks that occur within each framework activity are organized with respect to sequence and time
and is illustrated in figure below.
A linear process flow executes each of the five framework activities in sequence, beginning with
communication and culminating with deployment (Figure a). An iterative process flow repeats one or more
of the activities before proceeding to the next (Figure b). An evolutionary process flow executes the
activities in a “circular” manner. Each circuit through the five activities leads to a more complete version of
the software (Figure c). A parallel process flow (Figure d) executes one or more activities in parallel with
other activities (e.g., modeling for one aspect of the software might be executed in parallel with construction
of another aspect of the software).
PRESCRIPTIVE PROCESS MODELS
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.

WATERFALL MODEL
The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential approach to
software development that begins with customer specification of requirements and progresses through
planning, modeling, construction, and deployment, culminating in ongoing support of the completed
software.

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 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. In
reality, there is no fundamental difference between the classic life cycle and the V-model. The V-model
provides a way of visualizing how verification and validation actions are applied to earlier engineering work.
INCREMENTAL MODEL
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.

For example, word-processing software developed using the incremental paradigm might deliver basic file
management, editing, and document production functions in the first increment; more sophisticated editing
and document production capabilities in the second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth increment. It should be noted that the process
flow for any increment can incorporate the prototyping paradigm.
When an incremental model is used, the first increment is often a core product. That is, basic requirements
are addressed but many supplementary features (some known, others unknown) remain undelivered. The
core product is used by the customer (or undergoes detailed evaluation). As a result of use and/or evaluation,
a plan is developed for the next increment. The plan addresses the modification of the core product to better
meet the needs of the customer and the delivery of additional features and functionality. This process is
repeated following the delivery of each increment, until the complete product is produced.
The incremental process model focuses on the delivery of an operational product with each increment. Early
increments are stripped-down versions of the final product, but they do provide capability that serves the
user and also provide a platform for evaluation by the user.
Incremental development is particularly useful when staffing is unavailable for a complete implementation
by the business deadline that has been established for the project. Early increments can be implemented with
fewer people. If the core product is well received, then additional staff (if required) can be added to
implement the next increment. In addition, increments can be planned to manage technical risks. For
example, a major system might require the availability of new hardware that is under development and
whose delivery date is uncertain. It might be possible to plan early increments in a way that avoids the use of
this hardware, thereby enabling partial functionality to be delivered to end users without inordinate delay.

EVOLUTIONARY PROCESS MODELS

Software, like all complex systems, evolves over a period of time. Business and product requirements often
change as development proceeds, making a straight line path to an end product unrealistic; tight market
deadlines make completion of a comprehensive software product impossible, but a limited version must be
introduced to meet competitive or business pressure; a set of core product or system requirements is well
understood, but the details of product or system extensions have yet to be defined. In these and similar
situations, you need a process model that has been explicitly designed to accommodate a product that
evolves over time.
Evolutionary models are iterative. They are characterized in a manner that enables you to develop
increasingly more complete versions of the software.
Two common evolutionary process models are prototyping paradigm and spiral model.

PROTOTYPING PARADIGM
Often, a customer defines a set of general objectives for software, but does not identify detailed requirements
for functions and features. In other cases, the developer may be unsure of the efficiency of an algorithm, the
adaptability of an operating system, or the form that human-machine interaction should take. In these, and
many other situations, a prototyping paradigm may offer the best approach.
The prototyping paradigm begins with communication. You meet with other stakeholders to define the
overall objectives for the software, identify whatever requirements are known, and outline areas where
further definition is mandatory. Prototyping iteration is planned quickly, and modeling (in the form of a
“quick design”) occurs. A quick design focuses on a representation of those aspects of the software that will
be visible to end users (e.g., human interface layout or output display formats). The quick design leads to the
construction of a prototype. The prototype is deployed and evaluated by stakeholders, who provide feedback
that is used to further refine requirements. Iteration occurs as the prototype is tuned to satisfy the needs of
various stakeholders, while at the same time enabling you to better understand what needs to be done.
Ideally, the prototype serves as a mechanism for identifying software requirements. If a working prototype is
to be built, you can make use of existing program fragments or apply tools (e.g., report generators and
window managers) that enable working programs to be generated quickly.

SPIRAL MODEL
Using the spiral model, software is developed in a series of evolutionary releases. During early iterations, the
release might be a model or prototype. During later iterations, increasingly more complete versions of the
engineered system are produced.
Using the spiral model, software is developed in a series of evolutionary releases. During early iterations, the
release might be a model or prototype. During later iterations, increasingly more complete versions of the
engineered system are produced.
A spiral model is divided into a set of framework activities defined by the software engineering team. Each
of the framework activities represent one segment of the spiral path illustrated in figure As this evolutionary
process begins, the software team performs activities that are implied by a circuit around the spiral in a
clockwise direction, beginning at the center. Risk is considered as each revolution is made. Anchor point
milestones—a combination of work products and conditions that are attained along the path of the spiral—
are noted for each evolutionary pass. 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. Each pass through the planning region results in
adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from the customer
after delivery. In addition, the project manager adjusts the planned number of iterations required to complete
the software.

AGILE PROCESS
Agility has become today’s buzzword when describing a modern software process. Everyone is agile. An
agile team is a nimble team able to appropriately respond to changes. Change is what software development
is very much about. Changes in the software being built, changes to the team members, changes because of
new technology, changes of all kinds that may have an impact on the product they build or the project that
creates the product. Support for changes should be built-in everything we do in software, something we
embrace because it is the heart and soul of software. An agile team recognizes that software is developed by
individuals working in teams and that the skills of these people, their ability to collaborate is at the core for
the success of the project.

Any agile software process is characterized in a manner that addresses a number of key assumptions about
the majority of software projects:
1. It is difficult to predict in advance which software requirements will persist and which will change. It is
equally difficult to predict how customer priorities will change as the project proceeds.
2. For many types of software, design and construction are interleaved. That is, both activities should be
performed in tandem so that design models are proven as they are created. It is difficult to predict how much
design is necessary before construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable (from a planning point of view) as we
might like.

Agility Principles
The Agile Alliance defines 12 agility principles for those who want to achieve agility:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the
customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to
the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust
them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.

EXTREME PROGRAMMING (XP)

Extreme Programming (XP) is the most widely used approach to agile software development. Although
early work on the ideas and methods associated with XP occurred during the late 1980s, the seminal work on
the subject has been written by Kent Beck. More recently, a variant of XP, called Industrial XP (IXP) has
been proposed. IXP refines XP and targets the agile process specifically for use within large organizations.

XP Values
Beck defines a set of five values that establish a foundation for all work performed as part of XP—
communication, simplicity, feedback, courage, and respect. Each of these values is used as a driver for
specific XP activities, actions, and tasks.
In order to achieve effective communication between software engineers and other stakeholders (e.g., to
establish required features and functions for the software), XP emphasizes close, yet informal (verbal)
collaboration between customers and developers, the establishment of effective metaphors for
communicating important concepts, continuous feedback, and the avoidance of voluminous documentation
as a communication medium.
To achieve simplicity, XP restricts developers to design only for immediate needs, rather than consider
future needs. The intent is to create a simple design that can be easily implemented in code). If the design
must be improved, it can be refactored at a later time.
Feedback is derived from three sources: the implemented software itself, the customer, and other software
team members. By designing and implementing an effective testing strategy, the software (via test results)
provides the agile team with feedback. XP makes use of the unit test as its primary testing tactic. As each
class is developed, the team develops a unit test to exercise each operation according to its specified
functionality. As an increment is delivered to a customer, the user stories or use cases that are implemented
by the increment are used as a basis for acceptance tests. The degree to which the software implements the
output, function, and behaviour of the use case is a form of feedback. Finally, as new requirements are
derived as part of iterative planning, the team provides the customer with rapid feedback regarding cost and
schedule impact.
Beck argues that strict adherence to certain XP practices demands courage. A better word might be
discipline. For example, there is often significant pressure to design for future requirements. Most software
teams succumb, arguing that “designing for tomorrow” will save time and effort in the long run. An agile XP
team must have the discipline (courage) to design for today, recognizing that future requirements may
change dramatically, thereby demanding substantial rework of the design and implemented code.
By following each of these values, the agile team inculcates respect among its members, between other
stakeholders and team members, and indirectly, for the software itself. As they achieve successful delivery
of software increments, the team develops growing respect for the XP process.

The XP Process
Extreme Programming uses an object-oriented approach as it's preferred development paradigm and
encompasses a set of rules and practices that occur within the context of four framework activities: planning,
design, coding, and testing.
Figure illustrates the XP process and notes some of the key ideas and tasks that are associated with each
framework activity. Key XP activities are summarized in the paragraphs that follow.
Scrum
Scrum (the name is derived from an activity that occurs during a rugby match13) is an agile software
development method that was conceived by Jeff Sutherland and his development team in the early 1990s. In
recent years, further development on the Scrum methods has been performed by Schwaber and Beedle.
Scrum principles are consistent with the agile manifesto and are used to guide development activities within
a process that incorporates the following framework activities: requirements, analysis, design, evolution, and
delivery.
Kanban process

Kanban process is nothing but a Board, which is called "Kanban Board." This board plays a vital role in
displaying the task workflow. It helps to optimize the flow of task between different teams. It is a method for
defining, managing and improving services for delivering knowledge work.

In this method, work items are printed visually. It allows team members to see the state of every piece of
work at every development stage. Moreover, a team member gets overview who's doing what and can
identify and eliminate problem areas in the process.

Kanban methodology allows reprioritizing work as per the need of stakeholders. As work moves from one
state to another, some extra work also added until the flow is steady. The team collaborates with each other
to improve the flow of work throughout the project. Kanban process is never restricted to set process and
defined sprint backlog. So, it offers flexibility for developers.

Kanban Principles

• Kanban process visualizes the workflow which is easy to understand.

• Encourage acts of leadership at all levels
• It helps to measure and improve Collaboration
• Respect the current process, roles & responsibilities
• Helps team to make process easy and explicit

Representation of Kanban Board

Reference:
Pressman, Roger S. Software Engineering: A Practitioner's Approach. New York: McGraw-Hill