Software Engineeering

8/11/2019 Software Engineeering

1/24

G R O U P M E M B E R S

N A M E : R E G N O

K E N N E D Y K I R E G E R I F /

L I N D A H A Y U M A I F / 2 7 / 1 1

E M M A N U E L O D E N Y I R E I F / 2 8 / 1 1

D E N N I S M A K H O H A I F /I A N O S U N D W A I F / 3 1

E R I C K W A I N A I N A I F /

SOFTWARE ENGINEEERING


2/24

TASK

Explain why you would consider using the followingsoftware process approaches for the MoiUniversity and Equity Bank system:

a) SCRUM Approach

b) Extreme Programming

c) Service oriented engineering

What issues have contributed to the success of each

approach?


3/24

SCRUM Approach

A method which is used to manage productdevelopment. In SCRUM, the entire team works asa whole for the purpose of achieving the entiregroup work together reaching a common goal

which is good for the whole project which is beingundertaken. SCRUM is a departure from thewaterfall method of management and majorlyemphasizes on the aspects that are associated with

communication and collaboration not forgetting aproperly functioning software which is easilyflexible and adaptable to emerging business trends.The project is divided into small fractions known

as sprints which are based on durations, say weeks.


4/24

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 thedevelopment team. Because the Product Owner has themost authority of the three roles, its also the role withthe most responsibility. The Product Owner is the singleindividual 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 managethe team but works to manage all obstructions to theproject.

Team Member: In the Scrum methodology, the team is

responsible for completing work.


5/24

Reasons for the Implementation of Scrummethodology in the Moi University and Equity

System

1. It will lead to the development of a product which isneeded

Scrum methodology sets room for incremental featuresin the system. in this case, the customer is given theproduct, 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 andrequirements. As such, those entities that strive to keep

up with these changes are the ones that are able tosurvive even during the turbulent competitive times. Inthis case, the Moi University and Equity Bank system willstill suffice even if there are changes in the market needs.


6/24

Reasons continue.

3. It enables control of costs

The period of the project is usually fixed most of thetime. Scrum methodology allows for specificationchange which also includes the customer in the entireproject. As such, there is an element of transparencyand all the relevant costs can be accounted for.

4. Scrum allows for efficient collaboration and customersatisfaction

In essence, this approach entails association with allrelevant stakeholders in the project. In this case, the

Moi University students are also involved in theproject. At the same time, they are the intendedcustomers so their thoughts and suggestions on theproject are taken in.


7/24


8/24

Reasons continue.

6. Change management is an element which is taken inby Scrum

Regular changes can be taken in when it comes to

this methodology. For instance, a change can beexhibited to the customer and if he or she takes inthis change then it can be implemented in the nextsprint. If the students see something which they

would like changed, they can put a suggestion andthis will then be implemented in the subsequentsprint.


9/24

Reasons continue.

7. Scrum is ideal for system development

Scrum methodology is indeed ideal for thedevelopment of complex systems or in the

implementation of those projects which have a longduration before completion.


10/24


11/24

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 asrapidly 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 thefeature 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 timeinterval (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.


12/24

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 organizingmetaphor, which provides an easy to remember namingconvention.

Simple Design: Always use the simplest possible design thatgets the job done. The requirements will change tomorrow, soonly 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 Testsare automated tests written by the developers to testfunctionality as they write it. Each unit test typically tests only a singleclass, or a small cluster of classes. Unit tests are typically written using aunit testing framework.


13/24

Principles of XP continues.

Acceptance Tests(also known as Functional Tests) are specifiedby the customer to test that the overall system is functioning asspecified. Acceptance tests typically test the entire system, or somelarge chunk of it. When all the acceptance tests pass for a given userstory, that story is considered complete. At the very least, anacceptance test could consist of a script of user interface actions and

expected results that a human can run. Ideally acceptance testsshould be automated, either using the unit testing framework, or aseparate acceptance testing framework.

Refactoring: Refactor out any duplicate code generatedin 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, allcode is reviewed as it is written.


14/24

Principles of XP continues

Collective Code Ownership: No single person "owns" a module. Anydeveloper is expect to be able to work on any part of the codebase at anytime.

Continuous Integration: All changes are integrated into the codebase atleast 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 ofovertime are treated as a sign that something is very wrong with theprocess.

On-site Customer: Development team has continuous access to a reallive customer, that is, someone who will actually be using the system. Forcommercial software with lots of customers, a customer proxy (usually theproduct manager) is used instead.

Coding Standards: Everyone codes to the same standards. Ideally, youshouldn't be able to tell by looking at it who on the team has touched aspecific piece of code


15/24

XP in the context of Moi universitysstudent self-service system

XP teams work in a series of fixed iteration cycles.Iterations typically last 1, 2 or 3 weeks each depending onthe team. (A given team will almost always use same theiteration size for every iteration. At the beginning of each

iteration, the team gets together with the customer for aplanning meeting. In that meeting, they go over thefeatures the customer wants done in that iteration,

breaking each feature down into individual engineeringtasks. Individual developers then sign up for specific

tasks, and estimate those tasks. No developer is allowedto sign up for more work in the coming iteration than hecompleted in the previous iteration.


16/24

XP in the context continues.

During the rest of the iteration, the team will implement thefeatures they signed up for, pair programming on allproduction code. All code is written test-first -- that is, thedevelopers don't write any code until they have a failing testcase. The developers write unit tests to test individual classes

and subsystems. The customer provides functional oracceptance tests to validate the features that the programmersare developing.

At the end of the iteration usually a week the programmersdeliver 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, andthe team goes home early. The next Monday everyone meetsagain to plan the next iteration, and the cycle repeats itself.


17/24

XP in the context continues.

Actual product release is almost a non-event. The customer takesthe delivered system from some iteration, and distributes it to endusers. The system is always very nearly defect-free, so the onlyquestion is when the developers have added enough functionalityto make it worthwhile for the end users to upgrade.

How does XP compare to other lightweight processes,like Scrum, and FDD?

Scrumis a lightweight process that is philosophically very closeXP. SCRUM focuses more effort removing impediments, withdaily stand-up meetings where programmers list any outside

issues that are impeding progress, and a Scrum Master who istasked with removing those impediments. Peter Coad'sFeature Driven Developmentis an iterative

lightweight process, but is much more hierarchical than XP, with achief programmer, who directs class owners, who direct featureteams.
http://www.controlchaos.com/http://www.togethersoft.com/about/from_peter_coad/index.jsphttp://www.togethercommunity.com/coad-letter/Coad-Letter-0070.htmlhttp://www.togethercommunity.com/coad-letter/Coad-Letter-0070.htmlhttp://www.togethersoft.com/about/from_peter_coad/index.jsphttp://www.controlchaos.com/


18/24

SERVICE ORIENTED ENGINEERINGPROCESS APPROACH

Service-oriented engineeringis a software process approachthat aims at coming up with a system that collects all services inone significant system. These services can communicate witheach program. The system can communicate with each other andit can involve either simple data passing or it could involve moreservices 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 fordifferent applications to convert data and add it in the businessprocess.

Service oriented engineering divides functions into differentservices that can be distributed over a system and can becombined to create a business cycle. These servicescommunicate with each other by passing data from one serviceto another, or by coordinating an activity between two or moreservices.


19/24

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 absolutenetwork address.

iii. Should have a published interface. Users of the service only need to seethe interface and can be oblivious to implementation details.

iv. Should stress on interoperability. Service users and providers can usedifferent implementation languages and platforms.

v. Be discoverable. A special directory service allows the service to beregistered, so users can look it up.

vi. Be dynamically bound. A service user does not need to have the serviceimplementation available at build time; the service is located and boundat runtime.

These characteristics describe an ideal service. In reality, servicesimplemented in service-oriented systems lack or relax some of thesecharacteristics, such as being discoverable and dynamically bound.


20/24


21/24

WHY WE CONSIDERED THE SERVICEORINTED ENGINEERING APPROACH.

The following are the reasons why we considered using the service orientedengineering approach in coming up with the joint application to be used by MoiUniversity and Equity Bank:-

The system to be developed is service oriented. i.e. it is a self-servicing systemincorporating; 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 platformand technology. Thus, it helps to manage complexity involved. Since our team has

very limited experience with the kind of networking complexity and distributedcomputing involved in this project this approach will save us a great deal.

Making effective use of Service oriented concepts; clients can be competentenough as the time needed for the development is considerably reduced becauseof the reuse. Since our clients (Moi University and Equity Bank) want to roll outthe system functionality as fast as it can be made available, this approach is the

best.


22/24

Reasons continues.

It allows an organization to leverage existing assets, rather thanbuilding a new product from scratch without making use of existingones. This also reduces the software development cycle and the costinvolved, thus a faster time-to-market is made possible.

With service-based system, software engineers can reuse code andeasily shift the system to incorporate new features, analysis toolsand interface systems. Normal architecture cannot be so easilychanged and often resists any significant changes, requiringexpensive upgrades and add-ons. This will make our maintenanceprocess easy.

When a business uses a service-oriented system, it tends to know itwell and prepare it ahead of time for changes and maintenance. Thisall leads to lower costs, since the business does not need to hirethird party specialists as often for software maintenance. When it istime to integrate new functions, the integration can progress moresmoothly and with less expense.


23/24

REFERENCES


24/24

REFERENCES

M. P. Singh, M. N. Huhns,Service-OrientedComputing, John Wiley & Sons, 2005.

Intel: Service-Oriented Enterprise, The TechnologyPath to Business Transformation,

http://www.intel.com/business/bss/technologies/soe/soe_backgrounder.pdfpresentations/

Erl, T.: Service-Oriented Architecture: Concepts,Technology, and Design. Prentice Hall (2005)

Michael N. Huhns, M.P.S.: Service-orientedcomputing: Key concepts and principles. IEEEInternet Computing 9(1) (2005) 7581
http://www.intel.com/business/bss/technologies/soe/soe_backgrounder.pdfpresentations/http://www.intel.com/business/bss/technologies/soe/soe_backgrounder.pdfpresentations/http://www.intel.com/business/bss/technologies/soe/soe_backgrounder.pdfpresentations/http://www.intel.com/business/bss/technologies/soe/soe_backgrounder.pdfpresentations/

Documents

Software Engineeering