GROUP MEMBERS

NAME: REG NO
KENNEDY KI REGER I F/
LI NDAH AYUMA I F/ 27/ 1 1
EMMANUEL ODENYI RE I F/ 28/ 1 1
DENNI S MAKHOHA I F/
I AN OSUNDWA I F/ 31
ERI CK WAI NAI NA I F/
SOFTWARE ENGINEEERING
TASK
Explain why you would consider using the following
software process approaches for the Moi
University and Equity Bank system:
a) SCRUM Approach
b) Extreme Programming
c) Service oriented engineering
What issues have contributed to the success of each
approach?

SCRUM Approach

A method which is used to manage product
development. In SCRUM, the entire team works as
a whole for the purpose of achieving the entire
group work together reaching a common goal
which is good for the whole project which is being
undertaken. SCRUM is a departure from the
waterfall method of management and majorly
emphasizes on the aspects that are associated with
communication and collaboration not forgetting a
properly functioning software which is easily
flexible and adaptable to emerging business trends.
The project is divided into small fractions known
as sprints which are based on durations, say weeks.

Roles of Scrum:

There are three main roles and they entail the following:
Product Owner: The Product Owner is responsible for
communicating the vision of the product to the
development team. Because the Product Owner has the
most authority of the three roles, its also the role with
the most responsibility. The Product Owner is the single
individual who must face the music when a project goes
wrong.
ScrumMaster: ScrumMaster acts as a facilitator for the
Product Owner and the team. He or she does not manage
the team but works to manage all obstructions to the
project.
Team Member: In the Scrum methodology, the team is
responsible for completing work.

Reasons for the Implementation of Scrum
methodology in the Moi University and Equity
System

1. It will lead to the development of a product which is
needed
Scrum methodology sets room for incremental features
in the system. in this case, the customer is given the
product, makes use of it and even puts suggestions of
better ways of improving it.
2. It increases competitiveness
The market is one which has ever changing needs and
requirements. As such, those entities that strive to keep
up with these changes are the ones that are able to
survive even during the turbulent competitive times. In
this case, the Moi University and Equity Bank system will
still suffice even if there are changes in the market needs.

Reasons continue.
3. It enables control of costs
The period of the project is usually fixed most of the
time. Scrum methodology allows for specification
change which also includes the customer in the entire
project. As such, there is an element of transparency
and all the relevant costs can be accounted for.
4. Scrum allows for efficient collaboration and customer
satisfaction
In essence, this approach entails association with all
relevant stakeholders in the project. In this case, the
Moi University students are also involved in the
project. At the same time, they are the intended
customers so their thoughts and suggestions on the
project are taken in.


Reasons continue.
5. It employs systematic risk management
Regular releases of modules that are associated with
the project brings about a situation which recognizes
problems as and when they emanate for the purpose
of timely reaction and/or avoidance. This is
especially if the risks or problems will pose as
stumbling blocks for the project as a whole.

Reasons continue.
6. Change management is an element which is taken in
by Scrum
Regular changes can be taken in when it comes to
this methodology. For instance, a change can be
exhibited to the customer and if he or she takes in
this change then it can be implemented in the next
sprint. If the students see something which they
would like changed, they can put a suggestion and
this will then be implemented in the subsequent
sprint.

Reasons continue.
7. Scrum is ideal for system development
Scrum methodology is indeed ideal for the
development of complex systems or in the
implementation of those projects which have a long
duration before completion.

Extreme programming
Extreme Programming is a discipline of software
development based on values of simplicity,
communication, feedback, courage, and respect. It
works by bringing the whole team together in the
presence of simple practices, with enough feedback
to enable the team to see where they are and to tune
the practices to their unique situation.

What are the basic practices of XP?

The 12 core practices of XP are:
The Planning Game: Business and development
cooperate to produce the maximum business value as
rapidly as possible. The planning game happens at
various scales, but the basic rules are always the same:
Business comes up with a list of desired features for the system.
Each feature is written out as a User Story, which gives the
feature a name, and describes in broad strokes what is required.
User stories are typically written on 4x6 cards.
Development estimates how much effort each story will take,
and how much effort the team can produce in a given time
interval (the iteration).
Business then decides which stories to implement in what order,
as well as when and how often to produce production releases of
the system.
Principles of XP continues.
Small Releases: Start with the smallest useful feature set.
Release early and often, adding a few features each time.
System Metaphor: Each project has an organizing
metaphor, which provides an easy to remember naming
convention.
Simple Design: Always use the simplest possible design that
gets the job done. The requirements will change tomorrow, so
only do what's needed to meet today's requirements.
Continuous Testing: Before programmers add a feature,
they write a test for it. When the suite runs, the job is done.
Tests in XP come in two basic flavors.
Unit Tests are automated tests written by the developers to test
functionality as they write it. Each unit test typically tests only a single
class, or a small cluster of classes. Unit tests are typically written using a
unit testing framework.
Principles of XP continues.
Acceptance Tests (also known as Functional Tests) are specified
by the customer to test that the overall system is functioning as
specified. Acceptance tests typically test the entire system, or some
large chunk of it. When all the acceptance tests pass for a given user
story, that story is considered complete. At the very least, an
acceptance test could consist of a script of user interface actions and
expected results that a human can run. Ideally acceptance tests
should be automated, either using the unit testing framework, or a
separate acceptance testing framework.
Refactoring: Refactor out any duplicate code generated
in a coding session. You can do this with confidence that
you didn't break anything because you have the tests.
Pair Programming: All production code is written by
two programmers sitting at one machine. Essentially, all
code is reviewed as it is written.

Principles of XP continues
Collective Code Ownership: No single person "owns" a module. Any
developer is expect to be able to work on any part of the codebase at any
time.
Continuous Integration: All changes are integrated into the codebase at
least daily. The tests have to run 100% both before and after integration.
40-Hour Work Week: Programmers go home on time. In crunch mode,
up to one week of overtime is allowed. But multiple consecutive weeks of
overtime are treated as a sign that something is very wrong with the
process.
On-site Customer: Development team has continuous access to a real
live customer, that is, someone who will actually be using the system. For
commercial software with lots of customers, a customer proxy (usually the
product manager) is used instead.
Coding Standards: Everyone codes to the same standards. Ideally, you
shouldn't be able to tell by looking at it who on the team has touched a
specific piece of code

XP in the context of Moi universitys
student self-service system

XP teams work in a series of fixed iteration cycles.
Iterations typically last 1, 2 or 3 weeks each depending on
the team. (A given team will almost always use same the
iteration size for every iteration. At the beginning of each
iteration, the team gets together with the customer for a
planning meeting. In that meeting, they go over the
features the customer wants done in that iteration,
breaking each feature down into individual engineering
tasks. Individual developers then sign up for specific
tasks, and estimate those tasks. No developer is allowed
to sign up for more work in the coming iteration than he
completed in the previous iteration.

XP in the context continues.
During the rest of the iteration, the team will implement the
features they signed up for, pair programming on all
production code. All code is written test-first -- that is, the
developers don't write any code until they have a failing test
case. The developers write unit tests to test individual classes
and subsystems. The customer provides functional or
acceptance tests to validate the features that the programmers
are developing.
At the end of the iteration usually a week the programmers
deliver a working system to the customer. The system may not
be complete, but all functionality that is implemented works
completely, without bugs. The customer accepts delivery, and
the team goes home early. The next Monday everyone meets
again to plan the next iteration, and the cycle repeats itself.

XP in the context continues.
Actual product release is almost a non-event. The customer takes
the delivered system from some iteration, and distributes it to end
users. The system is always very nearly defect-free, so the only
question is when the developers have added enough functionality
to make it worthwhile for the end users to upgrade.

How does XP compare to other lightweight processes,
like Scrum, and FDD?
Scrum is a lightweight process that is philosophically very close
XP. SCRUM focuses more effort removing impediments, with
daily stand-up meetings where programmers list any outside
issues that are impeding progress, and a Scrum Master who is
tasked with removing those impediments.
Peter Coad'sFeature Driven Development is an iterative
lightweight process, but is much more hierarchical than XP, with a
chief programmer, who directs class owners, who direct feature
teams.


SERVICE ORIENTED ENGINEERING
PROCESS APPROACH

Service-oriented engineering is a software process approach
that aims at coming up with a system that collects all services in
one significant system. These services can communicate with
each program. The system can communicate with each other and
it can involve either simple data passing or it could involve more
services collaborating with some other activities. Therefore it
means that connecting services to each other is needed.
Service oriented systems are used as business processes that are
packaged as services in our life. These systems are used for
different applications to convert data and add it in the business
process.
Service oriented engineering divides functions into different
services that can be distributed over a system and can be
combined to create a business cycle. These services
communicate with each other by passing data from one service
to another, or by coordinating an activity between two or more
services.

Qualities of a service in this approach.
For a Service Oriented Engineering Approach to be successful, a service
should have the following qualities:-
i. Be self-contained. The service is highly modular and can be
independently deployed.
ii. Be a distributed component. The service is available over the network
and accessible through a name or locator other than the absolute
network address.
iii. Should have a published interface. Users of the service only need to see
the interface and can be oblivious to implementation details.
iv. Should stress on interoperability. Service users and providers can use
different implementation languages and platforms.
v. Be discoverable. A special directory service allows the service to be
registered, so users can look it up.
vi. Be dynamically bound. A service user does not need to have the service
implementation available at build time; the service is located and bound
at runtime.
These characteristics describe an ideal service. In reality, services
implemented in service-oriented systems lack or relax some of these
characteristics, such as being discoverable and dynamically bound.

DRIVERS FOR SERVICE ORIENTED
SOFTWARE ENGINEERING APPROACH

In large organizations, the following types of organizational,
business, and technology changes drive a desire to use the
service oriented software engineering approach in development
of their system:
Integration with legacy systems i.e. Equity banks legacy system
Corporate mergers i.e. between Moi University and Equity Bank
Realignment of responsibilities through business
reorganizations
Changing business partnerships (e.g., relationships with
suppliers and customers)
Modernization of obsolete systems for financial, functional, or
technical reasons
Acquisition or decommission of software products
Sociopolitical forces related to or independent of the drivers
cited above i.e. it is a government directive that all universities
partner with a bank of their choice for easy financial tracking.

WHY WE CONSIDERED THE SERVICE
ORINTED ENGINEERING APPROACH.

The following are the reasons why we considered using the service oriented
engineering approach in coming up with the joint application to be used by Moi
University and Equity Bank:-
The system to be developed is service oriented. i.e. it is a self-servicing system
incorporating; service providers (Moi University and Equity Bank), service users
(students, lecturers, etc) and services like enrollment, registration and payment,
therefore the service oriented engineering approach which entails all these
(services, service providers and service users) is the best approach.
Service oriented engineering allows you to develop a complex product by
integrating different products from different vendors independent of the platform
and technology. Thus, it helps to manage complexity involved. Since our team has
very limited experience with the kind of networking complexity and distributed
computing involved in this project this approach will save us a great deal.
Making effective use of Service oriented concepts; clients can be competent
enough as the time needed for the development is considerably reduced because
of the reuse. Since our clients (Moi University and Equity Bank) want to roll out
the system functionality as fast as it can be made available, this approach is the
best.

Reasons continues.
It allows an organization to leverage existing assets, rather than
building a new product from scratch without making use of existing
ones. This also reduces the software development cycle and the cost
involved, thus a faster time-to-market is made possible.
With service-based system, software engineers can reuse code and
easily shift the system to incorporate new features, analysis tools
and interface systems. Normal architecture cannot be so easily
changed and often resists any significant changes, requiring
expensive upgrades and add-ons. This will make our maintenance
process easy.
When a business uses a service-oriented system, it tends to know it
well and prepare it ahead of time for changes and maintenance. This
all leads to lower costs, since the business does not need to hire
third party specialists as often for software maintenance. When it is
time to integrate new functions, the integration can progress more
smoothly and with less expense.


REFERENCES

M. P. Singh, M. N. Huhns, Service-Oriented
Computing, John Wiley & Sons, 2005.
Intel: Service-Oriented Enterprise, The Technology
Path to Business Transformation,
http://www.intel.com/business/bss/technologies/so
e/soe_backgrounder.pdfpresentations/
Erl, T.: Service-Oriented Architecture: Concepts,
Technology, and Design. Prentice Hall (2005)
Michael N. Huhns, M.P.S.: Service-oriented
computing: Key concepts and principles. IEEE
Internet Computing 9(1) (2005) 7581