Presentation on theme: "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."— Presentation transcript:
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
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.