COM332 – SA3

RAD, DSDM,OOA,RUP

• OO Methods– OO emerged in 1970’s in various fields in computer science– OO often associated with small-scale programming & rapid

prototyping– Both features facilitated by Smalltalk development environment

• Over past 10 years OO popular for:– Reuse– Data abstraction– Rapid prototyping– Affording powerful & intuitive approach to S/W development– Increased productivity

• UML Aims (Booch, Rumbaugh etc.)– Provide a ready-to-use, expressive, visual modelling

language so users can develop and exchange meaningful models

– Ability to extend and specialise core concept– Independence from programming languages and

development processes– Formal basis for understanding modelling language– Encourage growth of OO tools market– Support higher-level development concepts– Integrate best practices and methodologies

• UML Techniques– Static application diagrams

• Class diagrams• Object diagrams• Component diagrams• Deployment diagrams

– Dynamic behaviour diagrams• Use case diagrams• Sequence diagrams

– Activity diagrams• Collaboration diagrams• Statechart diagrams

– Organisation and management• Packages• Subsystems• Models

• OO Methodologies– OOA – Object Oriented Analysis– RUP – Rational Unified Process

• Object oriented analysis (OOA)– There has been a many different

approaches to the analysis and design of object oriented system, the most well known is Coad and Yourdon Object-Oriented Analysis (OOA) methodology.

– This approach was published before the advent of UML and was described in 1990

• Activities – finding class-and-objects

– identifying structures

– identifying subjects

– identifying attributes

– identifying services

• these are the activities need to be performed, not necessarily been seen as stages or sequential steps.

• Finding class-and-objects– This activity is about increasing the analysts

understanding of the problem domain and identifying relevant and stable classes and objects that will form the core of the application.

• Student Registration System Student is a class– Coad a nd Yourdon offer a set of helpful hints in

order to find relevant class-&-object• look for structures (see activity 2)• look at other systems with which this one interacts• ask what physical devices the system interacts with• examine the events that must be remembered and recorded• examine relevant physical, geographical and organisational

units

• Identifying the structure– Organise the class-&-objects into hierarchies that will enable

the benefits of inheritance to be realised

• Identifying subjects– Purpose of this is reduce the complexity of the model by

dividing or grouping it into more manageable and understandable subject areas.

• Defining attributes– Attributes of the class-&-object are defined. – For the class student - student number, name, address are

attributes

• Defining services– Services of the class and objects are defined.

• Create, delete, update etc.

• Rational Unified Process– In 1998 Jacobson stated that the methods war

was over by the introduction of UML – unified modelling language.

– Every one will use UML• He also recognise having a standardised modelling

language is not that all needed, people should know how to use it.

– UML is a modelling language, discovering what need to be modelled is quiet different.

– For this Jacobson, Rumbaugh, Booch, Kruchten and Royce developed and evolved a process that has become known as Unified Process and which utilizes UML for modelling.

• Jacobson doesn’t like the term method or methodology. He says– “a method[ology] is usually a set of interesting ideas and

general step-by-step descriptions. However, it typically does not guide developers in how to use it in commercial product development”

• he identifies a number of shortcomings of method[ologie]s– they are paper products, typically frozen in a book– they are rarely tried or tested on real products before

publication– they are simple introductions, insufficient for use in real,

typically complex projects– they focus on developing new systems at the expense of

evolving development and maintenance– they are rich in notations but lack semantics

• The unified process is described as use-case driven, architecture centric, iterative and incremental.– Use-case are used to capture the user

requirements. – Use case describes an element of the functionality

of the system that give the user a result of value. They thus focus on things of specific value to a particular user, and this way overcome the growth of wish list or vague general functionality.

– The system is designed based on the use-cases, implemented to support the use-cases, and is tested based upon the content of the use-cases.

– RUP is an architecture centred process. • The architecture contain the details of the

hardware, operating system, the database, network etc.

– RUP is also iterative and incremental because the authors believe the requirements cannot be fully and accurately defined initially at one go.

• Requirements evolve with improved understanding and change over time.

• RUP has a number of cycles which together makes up the development of a project and run through its life.

• Each cycle consists of four phases– inception– elaboration– construction– transition

• There are nine core process workflows in RUP. – Workflow is a sequence of activities that produces a result of

observable value. • Business modelling• Requirements• Analysis and design• Implementation• Test• Deployment• Configuration and change management• Project management• Environment (support: processes, methods, tools)

– RUP also have the concept of a worker, who actually performs the role.

• RUP workflows– Business modelling

• Establishing the context of the system being developed and the shape of the organisation in which the system is going to be deployed.

• Identifies the currents problems, areas for re-design, identification of business rules etc.

– Requirements• Establish with the stakeholders

– what the system should do and why, – identify the boundaries of the system, – estimate the costs and the timescale.

• Vision of the system is developed which is then translated into a use-case model

– Analysis and design• Convert the requirements from above into an

implementation specification. • Analysis ensures the functional requirements are met,

typically ignoring the non-functional requirements and the run-time environment.

• Analysis is the logical view of the system. • Design takes the output of the analysis and adapts it to

the constraints of the architecture and non-functional requirements.

– Implementation• Converts the designs into implementation

– Test• Test and verifies the interaction of components, that all

requirements have been implemented and a quality product has been developed.

– Deployment• Deploy the finished software. This involves testing the

software, training the end-user, migrating from existing system, packaging the software and installing the software.

– Configuration and change management• Tracks and maintains the integrity of the project.

Artefacts must be identified and stored, and the various history and versions controlled.

– Project management• Provides a framework for managing the project

and managing the risk. Also provides guidelines for planning, staffing, monitoring and generally performing the project management.

– Environment (support: processes, methods, tools)

• This is about supporting the project with relevant processes, methods, and tools in an organisation.

• SDLC – Traditional Waterfall Approach to IS development:– Emphasis on sequential activities– Pre-defined detailed deliverables– Separation of users from IT specialists

• Criticised for delivering systems that are:– Over budget– Over schedule– Not what users need– Exacerbate the ‘culture gap’

– Evolutionary Development– Staged or incremental approach that periodically delivers the

system that increasingly completes over the time– It evolves through iterations

– Prototyping– A prototype is an approximation of a type that exhibits the

essential features of the final version of that type– Functional, process, performance, organisational

– uses system development tools in bid to improve requirements analysis

– Unclear, unstable requirements– High innovative innovativeness

– what the users wants is what they get– prototyping can be seen as improved form of system investigation

& analysis & an aid to design

• RAD – Rapid Application Development– speeding up the development process – The need to develop information system more rapidly has

been driven by rapidly changing business needs – Incremental development

• Not all the system requirements are known in the beginning– Time boxing

• System divided into number of components– Fixed resources and time variable functionality

– The Pareto principle• 80/20 rule

– MoSCow Rules– JAD work shops– Prototyping

• Help to establish user requirements– Sponsor and Champion– Toolsets

– RAD Potential Strengths:• Better Client-Developer communication & collaboration• Encouraging change of mind by clients allowing systems to

evolve through changing business environment/client perspective

• Encouraging an effective learning environment for both developers & users

• Increasing client confidence• Facilitating earlier & more testing• Providing the potential for cost reductions• Reducing the deadline effect • Facilitating better interfaces• Reducing risk• Motivating users and developers

• Potential Weaknesses:– Management problems– Lack of control– Raised user expectations– Selecting & motivating the right users &

developers– Not viewing RAD as a fundamental change in

approach, attitude & philosophy

– Martin, (1991) suggests RAD is an example of an approach that uses prototyping as part of an overall methodology

– The most important characteristics of JMRAD

– It adopts the evolutionary/prototyping approach, is not based on the traditional life cycle

– Focuses upon identifying the important users and involving them via workshops at early stages of development

– It focuses on obtaining commitment from business users

– It requires a toolset with a sophisticated repository

• Four phases– Requirements planning– User design– Construction– Cutover

• Requirements planning – two techniques– JRP, JAD– JRP Joint requirements planning (identify high level

mgmt. requirements of system at ‘strategic level’• Participants – senior managers• vision & understanding of overall objectives of system – how

can contribute to goals & strategy of organisation• Workshops

– To identify priorities– To eliminate unnecessary functions

– Joint application design (JAD)• Also the main technique of user design phase (analysis &

design)• Business users and information system people

• User Design– Use JAD workshops– User design achieved by right environment, use of good

prototyping tools– Prototyping tools allow quick exploration of processes:

• Interfaces• Reports• Screens• Dialogues

– Developed and expressed using 4 diagramming techniques:• entity modelling:• Functional decomposition• DFD’s• Action diagrams

• Construction phase– Takes the user design into detailed design and code generation. – Under taken by information system professionals using a toolset – Small development SWAT (skilled with advanced tools) teams to

improve communication– Require to work quickly

• Maximum possible use of reusable design and code

– Therefore IS’s implemented at:• lower cost• higher quality• increased speed• meeting needs of business• leading to lower maintenance costs

• Cutover– Involves further comprehensive testing using

realistic data in operational situation. – The user trained on the system– Organisational changes are implemented– Final cutover is effected by running the old and

new system in parallel until the new system is proved itself and the old system is phased out.

• JMRAD adopts the evolutionary or timebox approach to the development and implementation.– Recommends the system implementation is 90 days.

– The objective is to have the easiest and most important 80 percent of the system functionality produced in the first 90-day time box and the rest in the subsequent time boxes.

– The advantage of timebox is that it creates a focus on achieving an implementation in the specified period. In order to achieve this functionality must be trimmed accordingly.

– The timebox approach contrast with traditional approach where every conceivable requirement is implemented together & resulting complexity often cause delays.