7 Modeling 11 Pring eling Process, Principle id by extension, developme, to every soi del you choose y ose is prescriptive or ag Pproach. Every aspect of the work yo ul al APDrOACH as simple as possible, keep ever possible, ake decisions locally wh 1 Work prod cts you produce as concise as Principle 2; S ity 7 7 i 0 : ple 2: Focus on quality at every Step. The exit condition for every process activity, action, and task Should focus on the quality of the work prochct thee been produced. Principle 3: Be ready to adapt. Process is not a religious experience, adapt your approach to constraints imposed by the problem, t © peopl Principle 4: Build an effective team, Software engineering process and practice are important, bu ine is people. Build a self- organizing team that has mutual trust and respect. and has no place in it. When necess and the project its 1¢ bottom Principle 5: Establish mechanisms for communication and coordination, Projects fail because fron inte Ector falls into the cracks or stakeholders fail to coordinate their efforts to create a successful end produc’ info ders fale These are management issues and they must be addressed, Principle 6: Manage e approach may be either formal or informal, but mechanisms must be change. Th a y establish ei to manage the way changes arc requested, assessed, approved. and implementes 7 "s essential that you P s is being developed. It’s essenti a 0 Wrong as software ig curity engineering tasks. ni 7: As sk. Lots of things can go wrong as softy ing develop ss ee aaa plans. Some of these contingency plans wi form the bi i ingency plans. establish conti reate only those work products that ide value for others. Create only t rots hat r ialipravide tae et that is produced as part 0 Princ comer ceive sensi Iter cel fimetions and features will be ° u ail : cone clse, A list of re 7 aah roe al Tang practice wl e pase gh 1 SOM the design wil be passed along to those wh 2 to the perso assed along 10 passe and so on. generate code, and SOO 2 ioe That Guide Prac!wooo seemeanepenuusnit LOL IML) LECHMIUes, 3Q. Establishing The GroundWork Requirements engineering is simply a matter of conducting meaningful conversations with colleagues who are well-known members of the team. 3.1. Identifying Stakeholders A stakeholder is anyone who has a direct interest in or benefits from the system that is to be developed. At inception, you should create a list of people who will contribute input as requirements are elicited. 3.2. Recognizing Multiple Viewpoints Because many different stakeholders exist, the requirements of the system will be explored from many different points of view. The information from multiple viewpoints is collected, emerging requirements may be ‘consistent or may conflict with one another,3.3. Working toward Collaboration The job of a requirements engineer is to identity ty inconsistency. It is, ofcourse, the latter category that presents a challenge. Collabot mean that requirements are defined by committee. In many cases, stakeholders col, view of requirements, but a strong “project champion’ (e.g., a business manager or make the final decision about which requirements make the cut. 1 3.4 Asking the First Questions Questions asked at the ince] tion of the project should be “4 questions foot ‘context free” | 's on the customer and other stakeholders, the overall project goals + Who is behind the trequest for this work” + Who will use the solution? * What will be the econo mic benefit of a suc + Is there ful solution? another source for the solution that you need?14 Q. Analysis Packages An important part of analysis modeling is categorization. That is, various elements of the analysis model (e.g., use cases, analysis classes) are categorized in a manner that packages them as a grouping—called an analysis package— that is given a representative name. SAtogonist {SuyportingRole Fig : PackagesCMM's five maturity leve i 5. eve eee tuicu, Initial Level: Processes are ne Bs a of the individual werkien aoe ereanized ane a success of a project depends only on the competence . ao x ig 1 May not be able to repeat Past successes in future projects. The probability of exceeding the estimated cost and schedule is high. : Repeatable Level: In this level, successes of the past could be repeated because the organization uses project management techniques to track cost and schedule. Management according to a documented plan helps in the improved process. Defined Level: Organization’s set of standard processes are defined and are slightly modified to incorporate each project demands. This provides consistency throughout the works of the organization. Managed Level: Management of processes using quantitative techniques improves performance. assessed through data collection and analysis. are monitored and improved through feedback from current work. ed to cope with changing business objectives and the environment. Processes are Optimizing Level: Processes @ Innovative techniques are appli CMMI maturity levels include:er cesses that are not performed or partially evels includ! ete processes are pr t certain objectives relat CMMI capability ! fied by processes and ye es are monitored by Level 0: Incomplete — Incomp] goals are satis work can be done. managed and process| nd sel « Level 3: standard procs « Level 4: Quanti management of pro' « Level 5: Optimized through jnnovations and natu . performed. « Level l: Performed — Specific quality, cost and schedule are not met. Useful « Level 2: Managed — Cost, quality and schedule are management techniques. Defined — It includes management and additionally follow the organization’s spec esses which are altered for each project. atistical and quantitative techniques are used for the ely Managed proces tatively Managed — St cesses. — It focuses on continuous improvement of Quantitativ re of processes. ,The classical waterfall model divides the life cyele into a set of phases. This model cor phase can be started after the compiction of the previous phase. That is the output of one phas to the next phase. Thus the development process can be considered as a sequential flow ue the the phases do not overlap with each other. The different sequential phases of the classical waterfall shown in the below figure. ERAT ARS AND os SPECIFICATION cance nhases in detail. =n ca eanhnically feasible15.2 Human Factors Agile development focuses on the talents and skills of individuals, molding the process to specific people and teams.” The key point in this statement is that the process molds to the needs of the people and team * Competence: In an agile development context, “competence” encompasses innate talent, specific software- related skills, and overall knowledge of the process that the team has chosen to apply. Skill and knowledge of process can and should be taught to all people who serve as agile team members. * Common focus: Although members of the agile team may perform different tasks and bring different skills to the project, all should be focused on one goal—to deliver a working software increment to the customer within the time promised. To achieve this goal, the team will also focus on continual adaptations (small and large) that will make the process fit the needs of the team.d usin: sg) is about assessing, analyzing, yg information that will help 1 software and relevant databases) tha {less of proce: re team; creatit nformation (compute: mplish these tasks, b * Collaboration: Software at is communicated to the s and building To acco information understand the work of the team business value for the customer. sam members must collaborate— provides one another and all other takeholders. + Decision-making ability: Any good soltwi control its own destiny. This implies that the t technical and project issues. + Fuzzy problem-solving ability: to deal with ambiguity and will cont + Mutual trust and respect: The agile tear jelled team exhibits the trust and respect that are nec greater than the sum of the parts.” * Self-organization: In the context of agile development, self-organization implies thre: things: (1) the agile team organizes itself for the work to be done, . ca . a t 2) ne team organizes the process to best accommodate its local environment, bas See mera eee to best achieve delivery of the software increment. Self-organization s. but more importantly, it serves to i A st ted morale. y, it serves to improve collaboration and boost team are team (including agile teams) must be allowed the freedom tc eam is given autonomy—decision-making authority for both agile team will continually have Sofiware managers must recognize that the inually be bulfeted by change. n must become what DeMarco and Lister call a “jelled” team essary 10 make them “so strongly knit that the whole A iseURPS—tunctionality, usabili ma are FuRI Y, usability, reliability, performance, and supportability. -FURPS , attributes repr ye FURPS quality attributes represent a target for all software design: . Functionality is as sessed by evaluating the feature set and capabilities of the program, the generality of the functions that are delivered, and the security of the overall s; stem. + Usability is assessed by considering human factors, overall aesthetics, consistency, nd documentation. + Reliability is evaluated by measuring the frequency and sev rity of failure, the accuracy of output results, the mean- time-to-failure (MTTF), the ability (o recover from failure, and the predictability of the program. + Performance is mea g. processing speed, response time, resource consumption, throughput, and efficiency. sured by considerin: he program (extensibility). adaptability, ore common term, maintainability—and in ¢ case with which a system can be installed, and * Supportability combines the ability to extend th serviceability—these three attributes represent a mo addition, testability, compatibility, configurability. thi the ease with which problems can be localized. 16.2 The Evolution of Software Design rocess that has now spanned almost six +) = aqntinuin inuing PI ae 7 nrograms andependence is assessed usi P : Indep using two qualitative criteria: cohes; + Cohesion and coupli pling. Cohesion is an indication of th oe fanats ‘elative interde ; € relative functional strength of a e relative interdependence among modules ith of a module. Coupling is an indication of Cohesion is a natural extension of the i ion-hidi s information- : 7 ingle task, requiring little interaction with other ae cohesive module performs a onhaeiye se ane : 's in other parts of a program. Stated imply, a cohesive module should do just one thing. Although you should always strive for high cohesion (i.¢., single-mindedness). a ition of interconnection among modules in a software structure. Coupling en modules, the point at which entry or reference is made Coupling is an indicé face. In software design, you should strive for the depends on the interface complexity betwe toa module, and what data pass across the inter’ lowest possible coupling.