Unformatted text preview:

Feature ~~'1.,iflt~~ .~Ivarl-I~t:rr.systems.oday,This is due in part toThis trend has also-' been influencedall kinds of information-from plainfrom one product release to the next how the product could be improved We wantsoftware that is better adapted to our needs, but that, in turn, merely makes thesoftware more complex. In short, we want more.We also want it faster. Time to market is another important driver.Getting there, however, is difficult. Our demands for powerful, complex softwarehave not been matched with how software is developed Today, most people de-velop software using the same methods that were used as long as 25 years ago. Thisis a problem. Unless we update our methods, we will not be able to accomplish ourgoal of developing the complex software needed today.The software problem boils down to the difficulty developers face in pulling to-gether the many strands of a large software undertaking. The software developmentcommunity needs a controlled way of workinf:i :: ~~s a process that integrates themany facets of software development It needs a common approach, a process that96IEEE Soft.a,. -I- May' June 1999Feature,~~User'srequirement.FIGURE t. ~ ~re deveIopme~ process.. provides guidance to the order of a team's ac-tiVities.. directs the tasks of individual developers andthe team as a whole.. specifies what artifacts should be developed,and. offers criteria for monitoring and measuring aproject's products and activities.The presence of a well-defined and well-man-aged process is a key discriminator between hyper-productive projects and unsuccessful ones. TheUnified Software Development Process-the out-come of more than 30 years of experience-is a so-lution to the software problem.THE UNIFIED PROCESS IN ANUTSHEL.L.The term user refers not only to human users butto other systems. In this sense. the term user repre-sents someone or something (such as another sys-tem outside the proposed system) that interactswith the system being de\-eioped An example of aninteraction is a human who uses an automatic tellermachine. He or she inserts the plastic card, repliesto questions called up by the machine on its view-ing screen, and receives a sum of cash. In responseto the user's card and answers, the system performsa sequence of actions that provide the user with a re-sult of value. namely the cash withdrawal.An interaction of this sort is a use case. A use caseis a piece of functionality in the system that gives auser a result of value. Use cases capture functionalrequirements. All the use cases together make upthe use-case model, which describes the completefunctionality of the system. This model replaces thetraditional functional specification of the system. Afunctional specification can be said to answer thequestion, What is the system supposed to do? Theuse case strategy can be characterized by addingthree words to the end of this question: for eachuser? These three Y«>rds have a very important im-plication. They force us to think in terms of value tousers and not just in terms of functions that mightbe good to have.However, use cases are not just a tool for speci-fying the requirements of a system. They also driveits design, implementation, and test; that is, theydrive the development process. Based on the use-case modef, developers create a series of design andimplementation models that realize the use cases.The developers review each successive model forconformance to the use-case model. The testers testthe implementation to ensure that the componentsof the implementation model correctly implementthe use cases. In this way, the use cases not only ini-tiate the development process but bind it together.Use-case d';~n means that the developmentprocess follows a flow-it proceeds through a seriesof workflows that derive from the U5e cases. Usecases are specified, use cases are desi;Jned, and atFirst and fotemost the Unified Process is a soft-ware development process. A software develop-ment ptOCeSs is the set of activities needed to trans-form a user's requirements into a software system(see Figure 1). Howe~r. the Unified !"~.:ess is morethan a single process; it is a generic process frame-work that can be specialized for a very large class ofsoftwale systems, for different application aleas, dif-ferent types of organizations, diffefent competencelevels, and diffelent project sizes.The Unified Process is component-based, whichmeans that the softwale system being built is madeup of smtwale components interconnected via wetl-defined interfaces.The Unified Process uses the Unified ModelingLanguage when preparing all ~uepriri(s of the soft-wale system. In fact, UMl is an integral part of theUnified Process-they were developed hand inhandHowever, the real distinguishing aspects of theUnified Process are captured in the three keywords-use-case driven, architecture-centriC, anditerative and incremental. This is what makes theUnified Process uI"'lique.::;;tiJr()~,,""'5 ,,-r.,.'1'-- ""~~-;I;J.'fTHE UNIFIED PROCESS IsUSE-CASE DRIVEN(j) rt f'-~,kj~ ~ ~Ik\..AiW(, :1J ~]I-i'i ft (\ .i:(" \' ".,A software system is brought into existence toserve its users. Therefore, to build a successful sys-tem we must know what its prospective users wanta nd needI'May! Jun. 1999 I- IEEEFeature".tIthe end use cases are the source from which thetesters construct the test cases.While It is true that use cases drive the process.they are not selected in isolatk)n. They a~~ k>pedin tandem with the system architecture. That is. theThe architecturesystem to evolve,developmentuse cases dri\-e the system architecture and the sys-tem architecture influences the selection of the usecases. Therefore. both the system architecture andthe use cases mature as the life cycle continues.THE UNIFIED PROCESS IsARCHITECTURE-CENTRICThe role of software architecture is similar in na-ture to the role architecture plays in building con-struction. The building is looked at from variousviewpoints: structure, services, heat conduction,plumbing. electricity, and so on. This allows abuilder to see a complete picture before construc-tion begins. Similarly, architecture in a software sys-tem is described as different views of the systembeing built.The software architecture concept embodies themost significant static and dynamk aspects of thesystem. The architecture


View Full Document
Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?