CONVENTIONALSOFTWARE MANAGEMENT ‘The waterfall model of conventional software management, ar] prevalent in many mature software organizations, has served its parp ee eee ee ce Mlusteates some of the estical discriminators in this transition See ee nea ee ee en design to code to testing, with ad hoc documentation that attempts tc eee‘The top 10 principles of conventional software management are ene eee ea ee ee ee ees ‘higher-order programming language. Cee eer Sas ee ee eet eee ea et 7. Assess quality with an independent team. ieee ee ec cod Oe eee geen eee ase nsInthe mid- 1990, three important analyses were performed on the sofiware enginecring industry All three analyses given the same general conclusion: The success rate for software projects is very lowSystem requirements Software requirements Analysis Program design Coding Testing Operations“There are five improvements tothe b canneries Senet ste Peete ) Maintain current ad complete documentation (Document the desig De ee een ea) Iavolve the customerWhat Happens in Practice Sequential activities: Requirements map Design mp Code mm Integration mplest Integration Begins Development Progress (% coded) Original Target Date Project ScheduleRequirements | Design- Coding Integration High a Controlled Risk & Management 5 = Pd wu x 2 & z i ° } Risk a Exploration { Elaboration | period } period i Low "Project Life CycleIterative Development Iteration 1 Iteration 2 y Iteration 3 ——————r» + Earliest iterations address greatest risks + Each iteration produces an executable release + Each iteration includes integration and testOR NG He PU SAU REN UNGa aso ees ee oe eT) eras Dee ee ee ee eee ee pape aa a NI en en Piomemerseneer poy mitweanergen weet T-poperrins br Sle ape I SSNS OUND Oe NODE VON Or Fen Paes ee ee ni oe I eee RN TSE MOET T (Only about 158% of software developmenteffortis devoted to progeamming ES eater ane eee eee eee Ee fee nord progeanns Software systemprodits cost 9 ties as much, ee eee cer ee Dea ete area eee eee mec 80% of the engineecng is consumed by 20% of the requirement tis consumed by 20% of the components Ped eee een rer eer 80% of the software srap and reworks caused by 20% of the errors Ce eee Se eet veer ais 80% of the engineeringis accomplished by 20% of the tool 80% of the progcessis made by 2% of the peoplexn- w Accelerate Risk Reduction Walker Royce, 1995 70%) ee ee ee ee eg eer ae swere available as commercial products, inckuding the operating system, database pane networking, and graphical user interface DC ee ee ee eee crea es eer eC ery the use of managed and measured processes, integrated automation environments, and Se a ee ee ee ea eee ee need to be custom built Technologies for envionment automation, size reduction, and process improvement are not independent of one another. In each new era, the Key is complementary growth in all techs sample, the process advances could not be used successfully without new component technologies and increased tool eeePRAGMATICSOFTWARE ESTIMATION: If there is no proper well-documented case studies then it is difficult to estimate the cost of the software. It is one of the critical problem in softwa In order to estimate the cost of a project the following three topics should be considered, Reese nas Whether to measure software size in SLOC or fanction point aed a good estimate There ate 4 lot of software cost estimation models are available such as, COCOMO, re CON MEE ECO Me ne ae ee Me SN SOFTCOST, and SPQR/20PREDOMINANT COST ESTIMATION PROCESSOFTWARE ECONOMICS Cee eee Reducing the size or complexity of what needs to be developed Improving the development proc Using more-silled personnel and better teams (aot necessarily the same thing) Pee Pee Trading off or backing off on quality thresholdsImportant trends in improving software economics Cost Model Parameters ‘Size Abstraction and component based cevelopment technologies Process Methods and techniques Personnel People factors Environment ‘Automation technologies and tools Quality Performance, quail, accuracy Trends Higher-order languages (C++, Ada 95), Ovject- conented (analysis, design, programming), reuse, commercial eomponents Hterative development, process maturity levels, architecture frst development, acquisition reform “Training and personnel ski development, ‘teamwork, win-win concitions Taigrated tools (visual modeling, compiler, editor, debugger, change management), open systems, hardware platform performance, automation of coaing, documentation, testing, analysis Hardware platform perfomance, demonstration: based aseosement, etatistical ualty controNat Re See NETCONEU MES Berea High Quality « oe eee ee ee Evaluate design alternatives eee Minimize Intellectual distance SeeNat Re Seo NE TONE U MES: Renee eee Inspect code Scorned People are key to success cee so eee + Understand the eustomer’s priority ea PN eee eee People and time are not interchangeableVa vn THE OLD WAY AND THE NEW PRINCIPLES OF MODERN SE en ee ers + Establish an iterative life-cycle process that confronts risk early + Transition design methods to emphasize component-based pan peeieas Se eee eee ere Enhance change freedom through tools that support round-tip eee eer ee eee ere eee nrg et Establish a configurable process that is economically scalableReview - The First Top Five Principles for a Modern ProcessInception | Elaboration | Construction | Transition Architecture | BetaReleases | Productsi} 3 INCEPTION PHASE ee esia ELABORATION PHASE Fr er ene ee eee ee of this pluse, the “enginceting "is considered complete and the project faces is reckoning Poe a ea ora eee ere barr tan eon ney Saree ee cary Pad caeenees laorting the vison establishing 4 high-Bdelity understanding of the eitical use cases that Peer ee eee ca Elaborting the proass and infusirutue (establishing the construction pe Poonam oernan) Ear ead See er Papers greesONSTRUCTION PHASE Dee eee Ce eet ee Ee ere ay AOS oe a eee ae eer Deegan ete ey ee ee er nT ayts é TRANSITION PHASE, e Se ee ee ee eee eee ee eee are ar eno et i ee ne oer Syachioniation and intepution of concusent construction inte comintent deployment ee ee ee Smet) pene ‘ ;Life — cycle software artifacts are organized into five distinct sets that are roughly partitioned by the undedying language of the st: requirement pee pee deploymentBeever Eee Requirements ‘Set Design Set sets consist of the requirement ee Sees Saenger alte ‘ipo rsElaboration | Construction | Transi Architecture | BetaReleases | ProductsLIFE CYCLE STAGES Architecture | BetaReleases | ProductsThe Management set captaces associated with process planning ‘nd execution. Management arifi ee eee Es pe conrnie nea ere Pe See eto Analysis of changes between the current version of the artifact and previous Major milestone demonstrations of the balance among all artfvets and i partial, the accuracy of the business ease and vision artifactsee ee ee eee a Pee Reduiraments. | Design Set ‘set ‘setTHE ENGINEERING SETS: ee ee ee ee eer eee Requirements | Design Set | Implementation | Deployment Set Set Set Lon document 1.Deignmodsts) | seurce code | Lirtegrted archtecure omoiemefies | 2Acsonted Skala deine 2 Stare hoger dats caper eaaertsEe ee et eT ey I. Iteration content TI, Measurableobjectives A. Evaluation criteria / 8, Follow-through approach ~ III. Demonstration plan — A, Schedule of activities 8, Team responsibilities IV. Operationalscenarios (use cases demonstrated) ‘A Demonstration procedures B._Traceabilty to vision and business caseSeba ine cena peneeran ee Se ra grape pemarcbir gpeers Seger peel De ee ee ee ey ae PFO gE Ie DET ET NET ae cee eee ee ane ee eae ee ee eaten Eevee rarest symone eens Penney odENGINEERIN In genesal seview, there are three engiceing art [Vision document — supports the contract berween the finding authocty and the arene ee ee ee eee ee ee) ees epczstional concept sing Bd shod describe the change rls fahewect in the vitor autem a Architecture Description — itis extracted from the design model and includes views of career te ee eee eats peraional concept of the requtements st will be achievedA. Objectives B. Constraints —— C. Freedoms II, Architecture views 4. Design view B, Process view C, Component view D. Deployment view LI, Architecture overview iI. Architectural interactions A. Operational concept under primary scenarios B. Operational concept under secondary scenarios ¢. Operational concept under anornalous scenarios Iv. Architecture performance Iv. Rationale, trade-offs, and other substantiationfoam?MODEL-BASED SOFTWARE TURES-MANAGEMENT PERSPECT el of software are used in an increasing number of projets tohandle the complesity of Application domains oe ioe eee ee arent eee le models can be appliedin dffecent phates of «software development process, research Leeman ects eee Cee See See een Open en ee Conroe om ee ee eee Se eee og eee een ateDee ee eee Ee nerd s/w development processes Achieving stable s/w architecture represents a significant project mil SN TA ce De eee ee a eee ‘between the problem space and the solution space \ The architecture and process encapsulate many of the important copmunications among individuals, teams, organizations, and stakeholders. Poor architectures and immature processes are often given as reasons for project failures,MC ARCHITECTURES-TEC PERSPECTIVEMODEL-BASED SOFTWARE ARCHITECTURES-TECHNICAL PERSPECTIVE Deployment: Descber the srctse of te deplopat st ee ec eon)