Process improvement & service oriented software engineering

Software Engineering
SWETA KUMARI BARNWAL 1
PROCESS IMPROVEMENT & SERVICE ORIENTED SOFTWARE ENGINEERING
Topics Covered:
Process Improvement: Process and product quality, Process Classification, Process
Measurement, Process Analysis and Modeling, Process Change, The CMMI Process
Improvement Framework.
Service Oriented Software Engineering: Services as reusable components, Service
Engineering, Software Development with Services.
SOFTWARE PROCESS IMPROVEMENT
Many software companies usually face issues in their software development projects and its
delivery. The issues can vary from lack of documentation, lack of following the process, lack
of process governance, lack of the integration and collaboration between the teams, lack of
requirements traceability, lack of technology management, …etc.
SPI is a methodology defined as a sequence of tasks, tools, and techniques to plan and
implement improvement activities to achieve specific goals such as increasing development
speed, achieving higher product quality or reducing costs.
Process & Product Quality
Process quality and product quality are closely related and process improvement
benefits arise because the quality of the product depends on its development process.
A good process is usually required to produce a good product.
For manufactured goods, process is the principal quality determinant.
Improvement
Planning
Improvement
Evaluation
Improvement
Implementation
Current Situation
Evaluation

For design-based activity, other factors are also involved especially the capabilities of
the designers.
Software Process Model:
A software process model is an abstraction of the actual process, which is being described.
It can also be defined as a simplified representation of a software process. Each model
represents a process from a specific perspective. Basic software process models on which
different type of software process models can be implemented:
1. A workflow Model:
It is the sequential series of tasks and decisions that make up a business process.
2. The Waterfall Model:
It is a sequential design process in which progress is seen as flowing steadily
downwards. Phases in waterfall model:
• (i) Requirements Specification
• (ii) Software Design
• (iii) Implementation
• (iv) Testing
3. Dataflow Model:
It is diagrammatic representation of the flow and exchange of information within
a system.
4. Evolutionary Development Model:
Following activities are considered in this method:
• (i) Specification
Product
Quality
Development
Technology
People Quality
Process Quality
Cost Time
& Schedule

• (ii) Development
• (iii) Validation
5. Role / Action Model:
Roles of the people involved in the software process and the activities.
PROCESS CLASSIFICATION
• Informal: No detailed process model. Development team chose their own way of
working.
• Managed: Defined process model which drives the development process.
• Methodical: Processes supported by some development method such as the RUP.
• Supported: Processes supported by automated CASE tools.
PROCESS MEASUREMENT
Wherever possible, quantitative process data should be collected
◦ However, where organisations do not have clearly defined process standards
this is very difficult as you don’t know what to measure. A process may have
to be defined before any measurement is possible.
Process measurements should be used to assess process improvements
◦ But this does not mean that measurements should drive the improvements. The
improvement driver should be the organizational objectives.
Classes Of Process Measurement
Time taken for process activities to be completed
◦ E.g. Calendar time or effort to complete an activity or process.
Resources required for processes or activities
◦ E.g. Total effort in person-days.
Number of occurrences of a particular event
◦ E.g. Number of defects discovered.
PROCESS ANALYSIS AND MODELLING
A software process model is an abstraction of the actual process, which is being described.
It can also be defined as a simplified representation of a software process. Each model
represents a process from a specific perspective.
◦ Process analysis: The study of existing processes to understand the
relationships between parts of the process and to compare them with other
processes.

◦ Process modelling: The documentation of a process which records the tasks,
the roles and the entities used. Process models may be presented from
different perspectives.
THE CMMI PROCESS IMPROVEMENT FRAMEWORK
CMM Model (Capability Maturity Model): CMM was developed by the Software
Engineering Institute (SEI) at Carnegie Mellon University in 1987.
• It is not a software process model. It is a framework that is used to analyze the
approach and techniques followed by any organization to develop software
products.
• It also provides guidelines to further enhance the maturity of the process used to
develop those software products.
• It is based on profound feedback and development practices adopted by the most
successful organizations worldwide.
• This model describes a strategy for software process improvement that should be
followed by moving through 5 different levels.
• Each level of maturity shows a process capability level. All the levels except
level-1 are further described by Key Process Areas (KPA’s).
Capability Maturity Model Integration (CMMI) is a successor of CMM and is a more
evolved model that incorporates best components of individual disciplines of CMM like
Software CMM, Systems Engineering CMM, People CMM, etc. Since CMM is a reference
model of matured practices in a specific discipline, so it becomes difficult to integrate these
disciplines as per the requirements. This is why CMMI is used as it allows the integration of
multiple disciplines as and when needed.
Objectives of CMMI:
1. Fulfilling customer needs and expectations.
2. Value creation for investors/stockholders.
3. Market growth is increased.
4. Improved quality of products and services.
5. Enhanced reputation in Industry.
CMMI Representation – Staged and Continuous :
A representation allows an organization to pursue a different set of improvement
objectives. There are two representations for CMMI:
• Staged Representation :
• uses a pre-defined set of process areas to define improvement path.
• provides a sequence of improvements, where each part in the
sequence serves as a foundation for the next.
• an improved path is defined by maturity level.
• maturity level describes the maturity of processes in organization.
• Staged CMMI representation allows comparison between different
organizations for multiple maturity levels.
• Continuous Representation:
• allows selection of specific process areas.
• uses capability levels that measures improvement of an individual
process area.

• Continuous CMMI representation allows comparison between
different organizations on a process-area-by-process-area basis.
• allows organizations to select processes which require more
improvement.
• In this representation, order of improvement of various processes can
be selected which allows the organizations to meet their objectives
and eliminate risks.
CMMI Model – Maturity Levels:
In CMMI with staged representation, there are five maturity levels described as follows:
1. Maturity level 1: Initial
• processes are poorly managed or controlled.
• unpredictable outcomes of processes involved.
• ad hoc and chaotic approach used.
• No KPAs (Key Process Areas) defined.
• Lowest quality and highest risk.
2. Maturity level 2: Managed
• requirements are managed.
• processes are planned and controlled.
• projects are managed and implemented according to their
documented plans.
• This risk involved is lower than Initial level, but still exists.
• Quality is better than Initial level.
3. Maturity level 3: Defined
• processes are well characterized and described using standards,
proper procedures, and methods, tools, etc.
• Medium quality and medium risk involved.
• Focus is process standardization.
4. Maturity level 4: Quantitatively managed
• quantitative objectives for process performance and quality are set.
• quantitative objectives are based on customer requirements,
organization needs, etc.
• process performance measures are analyzed quantitatively.
• higher quality of processes is achieved.
• lower risk
5. Maturity level 5: Optimizing
• continuous improvement in processes and their performance.
• improvement has to be both incremental and innovative.
• highest quality of processes.
• lowest risk in processes and their performance.
CMMI Model – Capability Levels
A capability level includes relevant specific and generic practices for a specific process
area that can improve the organization’s processes associated with that process area. For
CMMI models with continuous representation, there are six capability levels as described
below :
1. Capability level 0: Incomplete
• incomplete process – partially or not performed.
• one or more specific goals of process area are not met.
• No generic goals are specified for this level.
• this capability level is same as maturity level 1.
2. Capability level 1: Performed

• process performance may not be stable.
• objectives of quality, cost and schedule may not be met.
• a capability level 1 process is expected to perform all specific and
generic practices for this level.
• only a start-step for process improvement.
3. Capability level 2: Managed
• process is planned, monitored and controlled.
• managing the process by ensuring that objectives are achieved.
• objectives are both model and other including cost, quality, schedule.
• actively managing processing with the help of metrics.
4. Capability level 3: Defined
• a defined process is managed and meets the organization’s set of
guidelines and standards.
• focus is process standardization.
5. Capability level 4: Quantitatively Managed
• process is controlled using statistical and quantitative techniques.
• process performance and quality is understood in statistical terms and
metrics.
• quantitative objectives for process quality and performance are
established.
6. Capability level 5: Optimizing
• focuses on continually improving process performance.
• performance is improved in both ways – incremental and innovation.
• emphasizes on studying the performance results across the
organization to ensure that common causes or issues are identified
and fixed.
SERVICE ORIENTED SOFTWARE ENGINEERING
A web service is an instance of a more general notion of a service: "an act or performance
offered by one party to another. Although the process may be tied to a physical product, the
performance is essentially intangible and does not normally result in ownership of any of the
factors of production."
The essence of a service, therefore, is that the provision of the service is independent of the
application using the service. Service providers can develop specialized services and offer
these to a range of service users from different organizations.
Services are reusable components that are independent (no requires interface) and
are loosely coupled. A web service is:
A loosely coupled, reusable software component that encapsulates discrete functionality,
which may be distributed and programmatically accessed. A web service is a service that is
accessed using standard Internet and XML-based protocols.
Services are platform and implementation-language independent.
Benefits of a service-oriented approach:
• Services can be offered by any service provider inside or outside of an
organization so organizations can create applications by integrating services from
a range of providers.
• The service provider makes information about the service public so that any
authorized user can use the service.

• Applications can delay the binding of services until they are deployed or until
execution. This means that applications can be reactive and adapt their operation
to cope with changes to their execution environment.
• Opportunistic construction of new services is possible. A service provider may
recognize new services that can be created by linking existing services in
innovative ways.
• Service users can pay for services according to their use rather than their
provision. Instead of buying a rarely-used component, the application developers
can use an external service that will be paid for only when required.
• Applications can be made smaller, which is particularly important for mobile
devices with limited processing and memory capabilities. Computationally-
intensive processing can be offloaded to external services.
Services As Reusable Components
Reusable software components are designed to apply the power and benefit of reusable,
interchangeable parts from other industries to the field of software construction. Other
industries have long profited from reusable components. Reusable electronic components are
found on circuit boards. A typical part in your car can be replaced by a component made from
one of many different competing manufactures. Lucrative industries are built around parts
construction and supply in most competitive fields. The idea is that standard interfaces allow
for interchangeable, reusable components.
Reusable software components can be simple like familiar push buttons, text fields list boxes,
scrollbars, dialogs etc.
Reusable components add standardized interfaces and object introspection mechanisms to
widgets allowing builder tools to query components about their properties and behavior.
Software components need not be visible in a running application; they only need to be visible
when the application is constructed.
For example, the builder tool above shows a calculator component that is built from 16 button
components, a text field component, and a panel upon which the buttons and a text display are
placed. In addition, you can see five invisible components. These specific components hold
values or strings used by the calculator for intermediate calculations, operation codes, and
display strings, as well a boolean flag to determine when evaluation of a new expression is
started.
A programmer can move, query, or visually hook together components such as numeric value
holders, disk accessors, or network socket components with a mouse while operating a
builder tool. However, such components would do their work invisibly while the application
is running.

Service-Oriented Architectures
Service-oriented software engineering is as significant as object-oriented software
engineering. Building applications based on services allows companies and other
organizations to cooperate and make use of each other's business functions. Service-based
applications may be constructed by linking services from various providers using either a
standard programming language or a specialized workflow language.
Service-oriented architecture (SOA) is a means of developing distributed systems where
the components are stand-alone services. Services may execute on different computers
from different service providers. Standard protocols have been developed to support service
communication and information exchange.

Benefits of SOA:
• Services can be provided locally or outsourced to external providers
• Services are language-independent
• Investment in legacy systems can be preserved
• Inter-organizational computing is facilitated through simplified information
exchange
Key standards:
• SOAP (Simple Object Access Protocol): a message exchange standard that
supports service communication
• WSDL (Web Service Definition Language): allows a service interface and its
bindings to be defined
• WS-BPEL (Web Services Business Process Execution Language): a standard
for workflow languages used to define service composition
Existing approaches to software engineering have to evolve to reflect the service-oriented
approach to software development:
• Service engineering (software development for reuse): the development of
dependable, reusable services.
• Software development with services (software development with reuse): the
development of dependable software where services are the fundamental
components.
A service can be defined as:
A loosely-coupled, reusable software component that encapsulates discrete functionality
which may be distributed and programmatically accessed. A web service is a service that is
accessed using standard Internet and XML-based protocols
A critical distinction between a service and a component as defined in CBSE is that services

are independent. Services do not have a 'requires' interface. Services rely on message-based
communication with messages expressed in XML.
The service interface is defined in a service description expressed in WSDL (Web Service
Description Language). The WSDL specification defines:
• What operations the service supports and the format of the messages that are sent
and received by the service. The 'what' part of a WSDL document, called an
interface, specifies what operations the service supports, and defines the format of
the messages that are sent and received by the service.
• How the service is accessed - that is, the binding maps the abstract interface onto
a concrete set of protocols. The 'how' part of a WSDL document, called a binding,
maps the abstract interface to a concrete set of protocols. The binding specifies the
technical details of how to communicate with a Web service.
• Where the service is located. This is usually expressed as a URI (Universal
Resource Identifier). The 'where' part of a WSDL document describes the location
of a specific Web service implementation (its endpoint).
RESTful Services
Current web services standards have been criticized as 'heavyweight' standards that are over-
general and inefficient. REST (REpresentational State Transfer) is an architectural style
based on transferring representations of resources from a server to a client. This
style underlies the web as a whole and is simpler than SOAP/WSDL for implementing web
services. RESTful services involve a lower overhead than so-called 'big web services' and are
used by many organizations implementing service-based systems.
The fundamental element in a RESTful architecture is a resource. Essentially, a resource
is simply a data element such as a catalog, a medical record, or a document. In general,
resources may have multiple representations i.e. they can exist in different formats.
Resource operations:
• Create - bring the resource into existence.
• Read - return a representation of the resource.
• Update - change the value of the resource.
• Delete - make the resource inaccessible.
The Web is an example of a system that has a RESTful architecture. Web pages are
resources, and the unique identifier of a web page is its URL.
• POST is used to create a resource. It has associated data that defines the resource.
• GET is used to read the value of a resource and return that to the requestor in the
specified representation, such as XHTML, that can be rendered in a web browser.
• PUT is used to update the value of a resource.
• DELETE is used to delete the resource.
Disadvantages of RESTful approach:
• When a service has a complex interface and is not a simple resource, it can
be difficult to design a set of RESTful services to represent this.

• There are no standards for RESTful interface description so service users must
rely on informal documentation to understand the interface.
• When you use RESTful services, you have to implement your own
infrastructure for monitoring and managing the quality of service and
the service reliability.
Service Engineering
Service engineering is the process of developing services for reuse in service-oriented
applications. The service has to be designed as a reusable abstraction that can be used in
different systems. Generally useful functionality associated with that abstraction must be
designed and the service must be robust and reliable. The service must be documented so that
it can be discovered and understood by potential users.
Stages of service engineering include:
• Service candidate identification, where you identify possible services that might
be implemented and define the service requirements.It involves understanding an
organization's business processes to decide which reusable services could support
these processes. Three fundamental types of service:
o Utility services that implement general functionality used by
different business processes.
o Business services that are associated with a specific business
function e.g., in a university, student registration.
o Coordination services that support composite processes such as
ordering.
• Service design, where you design the logical service interface and its
implementation interfaces (SOAP and/or RESTful). Involves thinking about the
operations associated with the service and the messages exchanged. The number
of messages exchanged to complete a service request should normally be
minimized. Service state information may have to be included in messages.
Interface design stages:
o Logical interface design. Starts with the service requirements and
defines the operation names and parameters associated with the
service. Exceptions should also be defined.
o Message design (SOAP). For SOAP-based services, design the
structure and organization of the input and output messages.

Notations such as the UML are a more abstract representation than
XML. The logical specification is converted to a WSDL description.
o Interface design (REST). Design how the required operations map
onto REST operations and what resources are required.
• Service implementation and deployment, where you implement and test the
service and make it available for use. Programming services using a standard
programming language or a workflow language. Services then have to be tested
by creating input messages and checking that the output messages produced are as
expected. Deployment involves publicizing the service and installing it on a web
server. Current servers provide support for service installation.
Service Composition
Existing services are composed and configured to create new composite services and
applications. The basis for service composition is often a workflow. Workflows are logical
sequences of activities that, together, model a coherent business process. For example,
provide a travel reservation services which allows flights, car hire and hotel bookings to be
coordinated.
Service construction by composition:
Formulate outline workflow
In this initial stage of service design, you use the requirements for the composite
service as a basis for creating an 'ideal' service design.
Discover services
During this stage of the process, you search service registries or catalogs to discover
what services exist, who provides these services and the details of the service
provision.
Select possible services
Your selection criteria will obviously include the functionality of the services offered.
They may also include the cost of the services and the quality of service
(responsiveness, availability, etc.) offered.
Refine workflow
This involves adding detail to the abstract description and perhaps adding or removing
workflow activities.
Create workflow program
During this stage, the abstract workflow design is transformed to an executable
program and the service interface is defined. You can use a conventional
programming language, such as Java or a workflow language, such as WS-BPEL.
Test completed service or application
The process of testing the completed, composite service is more complex than
component testing in situations where external services are used.

Process improvement & service oriented software engineering

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Process improvement & service oriented software engineering

Similar a Process improvement & service oriented software engineering (20)

Más de Sweta Kumari Barnwal

Más de Sweta Kumari Barnwal (20)

Último

Último (20)

Process improvement & service oriented software engineering