WWW.BOOK.DISLIB.INFO
FREE ELECTRONIC LIBRARY - Books, dissertations, abstract
 
<< HOME
CONTACTS



Pages:     | 1 || 3 | 4 |   ...   | 9 |

«Sharam Hekmat PragSoft Corporation Contents 1. INTRODUCTION 1.1 PURPOSE 1.2 SCOPE 1.3 SOFTWARE TOOL 1.4 GLOSSARY OF TERMS 2. ...»

-- [ Page 2 ] --

• Data Models It should be emphasised that design decisions are made in all three types of modelling. In business modelling we do not simply record the way the business operates now (‘as-is’ processes), we also consider how it could operate with the potential benefit of introducing information systems that can streamline the business activities (‘to-be’ processes). In application modelling, we invent metaphors, screens, and abstractions that enable end-users to use the application as an effective and intuitive tool that blends with their work processes, rather than becoming an obstacle to their work. In system modelling, we invent software artefacts that collectively not only realise the functional requirements for the application, but also satisfy its non-functional requirements.

2.2 Lifecycle Reference Models A software lifecycle is a map, depicting the stages that a software system undergoes, from its original inception, to its final termination (i.e., from cradle to grave). There is, however, no universally agreed www.pragsoft.com 10 UML Process lifecycle that is suited to all software development projects. Various lifecycles have been invented for different purposes. Project characteristics (such as size, timeframe, volatility of requirements, architecture, technologies, expected system lifetime) influence the most appropriate choice of lifecycle for a project.

This section outlines different software lifecycles and their intended usage context. The relationship between the different lifecycles is managed through a gateway reference model. This is described first.

2.2.1 Gateways Reference Model Every software project involves a number of key milestones. Each milestone represents an important event, and provides a review opportunity to decide whether the project should proceed to the next

step. These milestones are called gates. Five universal gates are defined:

Gate Description 0 A business case exists for the proposed solution.

1 Business requirements have been specified and agreed upon.

2 An integration-tested release has been produced, ready for system testing.

3 The release has successfully passed system testing.

4 The release has successfully passed acceptance testing.

Not all gates are relevant to all lifecycles. Also, in some lifecycles a gate may be passed iteratively (i.e., one chunk at a time).

2.2.2 Linear Lifecycle Model The linear lifecycle model (also called the waterfall lifecycle) views software development as a set of phases that take place linearly (i.e., one after the other).

–  –  –

This lifecycle is largely outdated because of the common problems it suffers from:

• It assumes that it is feasible to produce an accurate specification of requirements before getting involved in the design and implementation of the system. Experience has shown that, in most cases, this is not practical. In practice, requirements often tend to be vague and incomplete.

Users are not certain of what they want and, once they see a working system in operation, tend to change their mind.

• It takes too long to produce a demonstrable system, during which time the business climate and hence requirements may change substantially. So by the time the system is delivered, it may be already obsolete.

UML Process 11 Copyright © 2005 PragSoft

• The impact of defects in earlier phases is far too great on later phases. For example, a requirements defect discovered during the coding phase may cost 100-1000 times a coding defect to correct.

• The rate of rework tends to increase substantially from phase to phase, because each phase tends to uncover defects in the deliverables of earlier phases. This in turn derails the project plan and often puts unrealistic pressure on the development team, which ultimately may result in their demotivation and break up.

• The track record of this lifecycle in the industry is very poor, with over 60% of projects never delivering, and of those delivered, over 50% not being used by the end-users.

Despite these shortcomings, the linear lifecycle does have a place in the software industry. Situations

where its application may be sensible include:

• Where the requirements are stable, well understood, and well documented. An example of this is the re-engineering of an existing system that is largely consistent with user requirements, but perhaps technologically obsolete.

• Where the system does not directly interact with end-users (e.g., firmware and communication software).

• Where there is a wealth of existing experience about the problem domain and the project team has had considerable experience of developing similar systems. For example, a company with a good track record of successfully developing payroll applications, is unlikely to hit nasty surprises when developing yet another payroll application.

2.2.3 Proof-of-Concept Lifecycle Model The Proof of Concept (POC) lifecycle is suited to situations where a proposed concept (e.g., a business process, an architecture) needs to be proven before making further development investment. This is largely a risk management tool: by verifying the suitability and effectiveness of an idea on a small scale, we minimise the potential loss resulting from its failure. In practice, most ideas are partially successful, and the POC provides an opportunity to address their shortcomings before implementing them on a large scale.





–  –  –

The POC lifecycle is simple, but iterative. It begins by establishing the objectives and the scope for the POC. The objectives must be clearly stated and, based on these, a modest scope should be

established. Here is an example:

–  –  –

The scope must be manageable, a good representative of the problem domain, and sufficiently rich to enable the verification of the objectives.

During design and coding in POC, emphasis is typically on speed of construction. Trade-off and corner cutting are acceptable practices, provided they do not conflict with the objectives. For example, in the above scenario, it would be perfectly acceptable to implement only rudimentary error handling. However, if one of the objectives were to verify system robustness under erroneous input data, then this would be unacceptable.

2.2.4 CBD Lifecycle Model The Component Based Development (CBD) lifecycle is an emerging lifecycle for the development of distributed client-server systems using component technology.

–  –  –

The Partial Modelling phase involves carrying out enough business/application/system modelling to define a meaningful build scope. A build delivers a well-defined set of business functionalities that end-users can use to do real work. In a process-centric information system, for example, a build may represent the realisation of one or more end-to-end business processes. The scope of a build is not a random selection, but rather a logical selection that satisfies specific development objectives.

Once a build scope is established, we need to decide which of the required components can be reused (e.g., already exist in the organisation or can be bought off-the-shelf) and which ones need to

be developed. Both these phases have their own mini lifecycles:

–  –  –

Reusing an existing component may require some adaptation. For example, the component interface might not be exactly what is required or some of the method behaviours may need alteration. This is achieved through adaptation, which involves wrapping the component with a thin layer of code that implements the required changes.

Building a new component should always begin with defining the component interface. This represents a permanent contract between the component and other components. Once the interface is defined and the intent of each method is established, the component can be designed and implemented.

With all the components for a build in place, the components are then integrated and tested.

Integration will require the writing of glue code that establishes the interaction between the components. Most component technologies allow this to be done productively using a scripting language.

An integrated build is then formally released (by going through system testing). This is then made available to end-users for evaluation. The evaluation environment may be the same as the development environment (for earlier builds that are not mature), or a pseudo live environment (for later builds that are sufficiently mature). The outcome of the evaluation influences the direction of subsequent builds.

2.2.5 DSDM Lifecycle Model The Dynamic Software Development Method (DSDM) lifecycle is another emerging lifecycle that is suited to the development of information systems (that have vague and/or unstable requirements) to tight time-scales. Unlike CBD, DSDM is independent of any particular technology, but like CDB, it relies on an iterative approach to development.

–  –  –

DSDM is also often referred to as RAD (Rapid Application Development). It consists of five main

phases:

• Feasibility study, which typically lasts a couple of weeks and assesses the suitability of the RAD approach to the business problem.

• Business study which scopes the overall activity and provides the baseline for subsequent work, including business functionality, system architecture, and development objectives.

• Functional model iteration which, through a series of prototyping iterations, establishes the application functionality. The prototypes are created for their functionality and not intended to be maintainable.

• Design and build iteration, which generates well-engineered prototypes for use in the intended environment.

• Implementation, which involves putting the latest increment into the operational environment and training the users.

The following diagram illustrates a key difference between DSDM and traditional methods. Whereas in the traditional methods, the functionality to be delivered is fixed and time and resources may vary to meet that functionality, in DSDM this is turned upside down: functionality is delivered to a fixed time and resource plan. This is based on a fundamental assumption that 80% of business functionality can be delivered in 20% of the time it takes to deliver the whole thing.

–  –  –

To achieve this, DSDM employs the timebox mechanism. For a given project, there is an overall timebox for the work to be done. This is hierarchically broken into shorter timeboxes of 2 to 6 weeks, which are the focus of monitoring and control activities. Each timebox has an immovable end date and a prioritised set of requirements assigned to it. Some of these requirements are mandatory and some of less priority. A timebox will produce something visible in order for progress to be assessed (e.g., a model or a component). Each timebox is inclusive of all its effort, and is divided

into 3 parts:

• Investigation, which is a quick pass to check that the team is taking the right direction.

• Refinement, which builds on the comments resulting from the review at the end of the investigation.

• Consolidation, which ties up any loose ends.

2.2.6 Small Change Lifecycle Model The Small Change (SC) lifecycle is a streamlined lifecycle suitable for making small changes to an existing system.

–  –  –

SC is especially suitable for implementing the type of changes undertaken in a minor release. For

example:

• Addition of a new piece of functionality that is fairly similar, in its design, to existing functionality.

• Enhancing or enriching an existing piece of functionality without changing its underlying design.

• Making cosmetic changes to the front-end.

• Making changes to the format (but not the logical structure) of input or output data (e.g., changing a report format).

–  –  –



Pages:     | 1 || 3 | 4 |   ...   | 9 |


Similar works:

«Bewegen im Zwischenraum Bewegen im Zwischenraum herausgegeben von Uwe Wirth, unter Mitarbeit von Julia Paganini Band 3 der Reihe Wege der Kulturforschung herausgegeben von Uwe Wirth und Veronika Sellier im Auftrag des Migros-Kulturprozent Mit Beiträgen von Tina Bawden, Michael Bies, Natalie Binczek, Kai Bremer, Jörg Dünne, Ottmar Ette, Hannes Fricke, Alexander Friedrich, Michael Gamper, Thomas Gloning, Alexander Honold, Linda Karlsson Hammarfelt, Bernhard Kleeberg, Markus Krajewski, Claudia...»

«December 2012 Bibliography of Oklahoma Palynology Brian J. Cardott Oklahoma Geological Survey Allen, K.C., 1980, A review of in situ Late Silurian and Devonian spores: Review of Palaeobotany and Palynology, v. 29, no. 3-4, p. 253-270. Allen, K.C., 1981, A comparison of the structure and sculpture of in situ and dispersed Silurian and Early Devonian species: Review of Palaeobotany and Palynology, v. 34, no. 1, p. 1-9. Barker, G.W., and G.D. Wood, 1989, Microplankton and spores from the Woodford...»

«Falschvorstellungen von Schülern in der Elektrochemie eine empirische Untersuchung Eine vom Fachbereich Chemie der Universität Dortmund genehmigte Dissertation zur Erlangung des akademischen Grades eines Doktors der Pädagogik vorgelegt von Annette Marohn 1.Gutachter: Prof. Dr. Hans-Jürgen Schmidt 2.Gutachter: Prof. Dr. Bernd Ralle Tag der mündlichen Prüfung: 2. August 1999 Inhaltsverzeichnis 0 KURZFASSUNG 1 EINLEITUNG 2 HINTERGRUND 2.1 Zur Entstehung von Falschvorstellungen 2.2...»

«Project Overview and Motivation Given the burgeoning interest in the Cascadia margin from a variety of NSF-supported programs, and the growing public awareness of seismic and tsunami hazards in the U.S. and elsewhere, detailed information on the structure of the subduction margin off Washington State is critically needed. In order to provide background data in support of the OBSIP North Array focus site, the OOI Endurance mooring line, a GeoPRISMS Discovery Corridor, and specifically a...»

«www.face-europe.org/ Page 1 of 8 Jagen in NORWEGEN GEBIET Norwegen hat eine Grundfläche von 385.155 km² und die abwechslungsreiche Natur ist Grundlage einer artenreichen Tierwelt und ermöglicht unterschiedliche Jagdformen und Jagderlebnisse. JÄGER/BEVÖLKERUNG Bevölkerung 4.000.000 Anzahl von Jägern 191.000 % Jäger 4,75% Einwohner/ Jäger 1/21 Bevölkerungsdichte Einwohner/km² 14 Sources: Directorate for Nature Management Trondheim www.njff.no/ www.face-europe.org/ Page 2 of 8...»

«Xerox® Phaser® 3020 / 3052 / 3260 Printer Imprimante Xerox® WorkCentre® 3025 / 3215 / 3225 Multifunction Printer Imprimante multifonction Xerox Phaser 3020 / 3052 / 3260 ® ® Xerox WorkCentre 3025 / 3215 / 3225 ® ® Warranty Garantie Italiano Garanzia Deutsch Garantie Español Garantía Português Garantia Русский Гарантия Attention: The warranty statement provided with this product may not apply if you purchase your product under a PagePack, eClick, or other written...»

«1
 
 Jürgen Oelkers Eros und Herrschaft: Ein anderer Blick auf die Reformpädagogik*) „Reformpädagogik“ ist mehr als nur eine Serie von privaten Schulgründungen in Deutschland vor und nach dem Ersten Weltkrieg. Aber diese „neuen Schulen“ sind stark beachtet worden, während die Reformansätze in den staatlichen Schulen, die es seit Mitte des 19. Jahrhunderts vielfach gegeben hat, bislang eher ignoriert oder als nachgeordnet betrachtet wurden. Auf der anderen Seite ist...»

«SETTLEMENT, TERRITORY, AND LAND USE IN THE EAST MIDLANDS: THE LANGTON HUNDRED c.150 BC c.AD 1350 Thesis submitted for the degree of Doctor of Philosphy at the University of Leicester by Paul Bowman BA (Econ) (Manchester) School of Archaeological Studies University of Leicester October 1995 UMI Number: U 077127 All rights reserved INFORMATION TO ALL U SE R S The quality of this reproduction is d ep endent upon the quality of the copy submitted. In the unlikely event that the author did not sen d...»

«A3 ACTA PHYSIOLOGICA A C A D E M I AE SCI ENTI A R U M HUNGARICAE ADIUVANTIBUS E. E R N S T, B. IS S E K U T Z sf.n., G. IV A N O V IC S, N. J A N C S Ó, K. LISSA K, E. T. S Z Ö R É N Y I RED IG I Г F. B. S T R A U B T O M U S I. F A S C IC U L U S 1. MAGYAR TUDOMÁNYOS AKADÉMIA BUDAPEST. 1950 A C TA PHYSIOL. H U N G. ACTA PHYSIOLOGIC A HUNGARICA A MAGYAR TUDOMÁNYOS AKADÉMIA KÍSÉRLETES ORVOSTUDOMÁNYI KÖZLEMÉNYEI SZERKESZTŐSÉG ÉS KIADÓHIVATAL : BUDAPEST V I, SZTÁLIN-ŰT...»

«ARTFUL INQUIRY: A SYMBOLIC CONSTRUCTIVIST APPROACH TO SOCIAL SCIENCE RESEARCH DAVID BARRY Victoria Management School Victoria University Wellington P. O. Box 600 Wellington, New Zealand +++ (644) 463-5141 +++ (644) 463-5253 (fax) email: david.barry@vuw.ac.nz Published in Qualitative Inquiry (1996, V2, #4: 411-438) Abstract This article introduces symbolic constructivism, a qualitative research approach which uses artlike, non-routine portrayal (e.g., sculpture, photographs, drawing,...»





 
<<  HOME   |    CONTACTS
2016 www.book.dislib.info - Free e-library - Books, dissertations, abstract

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.