Class Note for EECS 448 with Professor Niehaus at KU
Class Note for EECS 448 with Professor Niehaus at KU
Popular in Course
Popular in Department
This 15 page Class Notes was uploaded by an elite notetaker on Friday February 6, 2015. The Class Notes belongs to a course at Kansas taught by a professor in Fall. Since its upload, it has received 22 views.
Reviews for Class Note for EECS 448 with Professor Niehaus at KU
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 02/06/15
The Software Process Chapter 3 EECS 448 Dr Douglas Niehaus EECS 448 1 Dr Douglas Niehaus 2009 Overview Software process must adapt to the specifics of the situation Nature of the application Individuals involved Development period available Client characteristics Target platform constriants EECS 448 3 Dr Douglas Niehaus 2009 Overview The term software processquot refers to the way software is produced by an organization Different organizations have different processes All incorporate basic components of software development SW lifecycle model specific methods for analysis design and implementation tools and individual roles in building software Level of effort can vary widely Documentation selfdocumenting code to extensive volumes describing all aspects Testing 12 of budget to relying on customers Postdelivery 20 year contract DoD to none research la 3 EECS 448 2 Dr Douglas Niehaus 2009 Unified Process Currently dominant objectoriented methodology Collaborative effort of Rumbaugh object modelling technique GMT 1991 GE research and Development Center Booch Booch Method 1994 Rational nc Jacobson Objectory Methodology Called The Three Amigosquot Yet Another Stupid Programmer Joke Developed Unified Modelling Language UML Notation for describing an 00 SW product Version 10 published in 1997 International standards EECS 448 4 Dr Douglas Niehaus 2009 Unified Process Initially called Rational Unified Process Unified Process is not a specific set of steps Adaptable Modified to match the specific product Some features inapplicable to small and medium proiects Much of it is used for products of all sizes Iteration and lncrementation within the Object oriented paradigm 00 used throughout process modelling design implementation EECS 44B 5 Dr Douglas Niehaus 2009 Unified Process Unified Process recognises five workflows Requirements Analysis Design Implementation Testing Proficiency with UP requires considerable study and expenence Model was developed primarily for large complex products so application to smaller products requires experiencedbased adaptation Welwill make some arbitrary choices for the proiect EECS 44B 7 Dr Douglas Niehaus 2009 Unified Process A model is a set of UML diagrams describing elements or aspects of the product UML provide software professionals a common vocabulary within which to communicate OO Paradigm is incremental and iterative Each workflow consists of a number of steps Steps of each workflow are repeated as required for refinement as more knowledge is gained Goal is a UML diagram that all parties find satisfactory UML diagrams are made more accurateiteration and extended lncrementation EECS 44B 6 Dr Douglas Niehaus 2009 Requirements WorkFlow Development process usually begins with a customer approaching a development organization Requirements WF concentrates on determining the client s needs Clients do not always know what they need First step of the SWE is to acquire basic understanding of the application domain SWE must keep the client informed and demonstrate to the client that the SW will be costeffective Or development will stop Business model makes this case We will assume the semester project is a brilliant idea with respect to costeffectiveness EECS 448 Dr Douglas Niehaus 2009 Requirements WorkFlow At an initial meeting the client outlines their ideas for the product Descriptions may be vague unreasonable contradictory or Impossible Untangling such problems comes with increasing understanding of the problem and the product solving it Education of the SWE and the customer is an important part of this With greater understanding comes restating and rescoping the problem SWE determine the client s needs and associated constriants EECS 44B 9 Dr Douglas Niehaus 2009 Requirements WorkFlow Functionality of the proposed product is successively refined and analysed For technical feasibility and financial justification Though meetings among developers and with clients Developers often discover constraints implications or possibilities that the client had not considered What the client says they want may not be what they really need what will achieve their goals best What the developers think the client wants may not be what the clients needs Clients have incomplete knowledge as do all of us Software is complex and constraints often subtle EECS 44B 11 Dr Douglas Niehaus 2009 Requirements WorkFlow Major constraints are deadline and cost Others include reliability size platform user characteristics Cost is often handled through bidding Client rarely reveals the available budget Few SW organizations sayquotNo really please pay us lessquot Works against completely open and honest communication and can lead to problems later Only practical way to do it usually Concept exploration Preliminary exploration of client s needs and characteristics of problem domain EECS 44B 10 Dr Douglas Niehaus 2009 Analysis WorkFlow Goal of analysis workflow is to analyse and refine the discoveredextracted requirements to achieve a detailed understanding that is expressed in terms serving the design and implementation of software Requirements generally are expressed in terms familiar to the client promoting client understanding Analysis uses more precise language relevant to software implementation Constraints on software structure capabilities and behaviour are often useful Testable during development Encourage refinement of understanding Analysis generally defines product acceptance criteria EECS 44B 12 Dr Douglas Niehaus 2009 Analysis WorkFlow Acceptance criteria should be complete Client should be satisfied with a product that satisfies the criteria Specifications should avoid terms that are imprecise Untestable and nonoperational Eg suitable ample convenient When noted they must be refined by defining what is suitable to a situation what file capacity is ample and what response time is convenient Specifications should be written as if they will be used in a lawsuit ideally in theory Specifications are essential for both testing and maintenance EECS 44B 13 Dr Douglas Niehaus 2009 Analysis WorkFlow UML diagrams combined with narrative descriptions are less likely to contain such ambiguities omissions and contradictions Sti possible however Once the client approves the specifications detailed planning and estimation begins Duration and cost of the project Clients require estimates and schedules with milestones that can be checked against reality Assigning personnel to various workflows Software management plan presents these issues to both client and developers EECS 44B 15 Dr Douglas Niehaus 2009 Analysis WorkFlow Under the Unified Process there is no specification document Set of UML models is supposed to be sufficient However this does not mean that the presentation of the analysis is without explanation and narration Narrative helps the reader interpret the UML and other diagrams Issues with classical analysis Ambigui y some sections could have more than one vali interpretation Incompleteness some vital component may be missing Contradictions EECS 44B 14 Dr Douglas Niehaus 2009 Analysis WorkFlow Software Product Management Plan SPMP Describes the separate workflows of product Shows members involved with each task Deadlines for each task Major components of SPMP Deliverables what the client will receive Milestones when the client receives incrementally improved versions of the product Budget how much is it all going to cost Time is the biggest component of money EECS 44B 16 Dr Douglas Niehaus 2009 Design WorkFlow Goal of design workflow is to refine analysis components until the description of the problem solution is in a form that can be implemented as software by programmers A design shows how a product is going to satisfy constraints and provide capabilities extracted by the requirements workflow and described operationally by the analysis workflow Classical Design Phase Determine the internal structure of the product Decompose the product into modules Independent code with welldefined interfaces Detailed Design select algorithms and data structures for each module EECS 44B 17 Dr Douglas Niehaus 2009 Implementation WorkFlow Goal of implementation workflow is to implement the designed target software product In the chosen languages Large products may involve several commands or components implemented in parallel by separate teams Subsystems are generally implemented by individuals or small groups 23 Operational code artifacts Usually programmers are only given the design artifacts as this should provide enough information for implementation Rarely shown architectural level design EECS 44B 19 Dr Douglas Niehaus 2009 Design WorkFlow ObjectOriented Design Phase Describe product components as objects which are a kind of module Some code is more easily described as procedures so not all designs are purely OO Strong correspondence among components extracted during analysis workflow and objects designed in design workflow as both are 00 Design teams should keep a logdiary of design options and decisions to aid in Backtracking in case of deadends or contradiction Maintenance and future enhancements EECS 44B Implementation WorkFlow 18 Dr Douglas Niehaus 2009 This can be a mistake however as analysis and requirements level information can be helpful in understanding the goals and context of a design Mistakes can be at the design level or earlier These mistakes sometimes are first observed as difficulties or contradictions in implementation Obviouslyit however the broader view can be too large an problem to be helpful Can be a distraction certainly arremoved from the implementation The larger the product the more likely looking at EECS 448 only the design is to be necessary 20 Dr Douglas Niehaus 2009 Test WorkFlow Test WorkFlow Under the Unified Process the test workflow is carried out in parallel with other workflows SWE test and retest each artifact they develop or maintain Nature of the artifact strongly influences the form of testing eg requirement vs subroutine Next the SQA group performs independent testing of the artifact SQA often test at larger granularity than developers Independently developed tests as derived from design and specification descriptions is key Traceability is important to all artifacts EECS 44B 21 Dr Douglas Niehaus 2009 Test WorkFlow Traceability refers to the ability to identify the derivation of the artifact from the software process Modules must be traceable to design components which are then traceable to analysis and requirements artifacts Requirements Artifacts Should be traceable forward to analysis design and implementation artifacts Should be traceable to specific customer requests where possible though some are discovered Should be presented methodically Numbered crossreferenced indexed Simplifies SQA EECS 44B 22 Dr Douglas Niehaus 2009 Test WorkFlow Analysis Artifacts Checked by both analysis team and SQA Must look for faults in specification contradictions omissions as well as feasibility Reviews are a good way of checking analysis artifacts Group of people listening to the line of argument presented should include requirements and client representatives Meeting often chaired by SQA group Review is still largely rhetorical as much of the argument is still in human language Walkthroughs and inspections of arguments EECS 44B 23 Dr Douglas Niehaus 2009 Checking of detailed planning and estimations Once the client signs off specifications Every aspect of SPMP is checked Particular attention to plan s duration and cost estimates to reconcile any significant differences in interpretation Multiple independent estimates valuable when possible Client decides if plan and estimates are acceptable EECS 44B 24 Dr Douglas Niehaus 2009 Test WorkFlow Design Artifacts Every design component should be traceable ie crossreferenced to analysis artifacts Major component of testing is determining if each part of the design is consistent with the specifications Also is every part of the specifications reflected in some part of the design Design reviews are similar to AnalysisSpecification reviews in that a diverse group consider the issues However clients are not usually present Faults to look for include logic interfacelack of exception handling inconsistency with specs EECS 44B 25 Dr Douglas Niehaus 2009 Test WorkFlow How components are integrated influences success As ready or all at once Topdown or Bottomup Incremental model strongly indicates that components and capabilities should be integrated as available and as continuously as possible Usecase driven development Thin vs Thick development model SQA determines if combined components integrate and collaborate correctly in service of product Developers should be trying a lot of this SQA is official signoff not first discovery as possible EECS 44B 27 Dr Douglas Niehaus 2009 Test WorkFlow Implementation Artifacts lnformal testing by implementer as they are implemented Desk Testing Tested as components after completion Against defined test cases Unit Testing by SQA tests the components methodically Code review is powerful and successful technique Programmer guides review off their code Must include SQA representative Scary but always reveals new ideas EECS 44B 26 Dr Douglas Niehaus 2009 Test WorkFlow SQA has primary responsibility to show that a product satisfies its specifications and all acceptance criteria Product Testing Listed constraints must be satisfied Functionality must be complete Robustness of product should be evaluated Scaling of data sets Unexpected input Effects of new product on existing SW Completeness of source code and documentation EECS 44B 28 Dr Douglas Niehaus 2009 Test WorkFlow PostDelivery Maintenance Acceptance Testing An integral part of the process for real software Checking satisfaction Of Client constraints and Not feasible for classroom projects as the software capabilities by software delivered to client Should must include client hardware and client environment COTS SW Alpha versions of complete product provided to select clients for realistic testing Testers expect some problems and have positive view of finding them Beta larger set of users fewer faults expected Sometimes called Release Candidates RCx Not a substitute for SQA EECS 44B 29 Dr Douglas Niehaus 2009 PostDelivery Maintenance is not used for long enough ls part of software for many research projects Must be part of original planning Design should take future enhancements and mechanism changes into account Strong encapsulation a major advantage of OO Largest part of development monetarily Currency existence of documentation is often biggest maintenance challenge Often have tight deadlines or are crisis driven EECS 44B 30 Dr Douglas Niehaus 2009 Retirement Maintenance Large turnover is common Not the easiest or most fulfilling job Often stressful Testing in this context has two major components Checking correctness of specific changes Checking that changes have not caused regression faults Automation of test cases is key so the can be used to check wide range of previous ehaviour after all changes Log of all changes made is VITAL Often in Comments in source code EECS 44B 31 Dr Douglas Niehaus 2009 Final stage of the life cycle Often after many years of service Reasons Proposed changes are sometimes so drastic that starting over at an earlier phase design analysis even requrrements makes more sense Cumulative entropy from many years of maintenance can create module interdependencies that a new implementation is required Lack of documentation increases chance of regression faults Hardware replacement may force reImplementatIon EECS 44B 32 Dr Douglas Niehaus 2009 Phases of Unified Process In theory there could be an arbitrary number of increments in practice there are usually four phases All workflows present in all phases Inception emphasizes requirements some analysis exploratory designimplementationtest Elaboration emphasizes analysis and design but requirements are refined and more implementation and testing of ideas happens Construction emphasizes implementation but design refinement can be large and ramp up of testing in parallel with component implementation Transition emphasizes testing for correctness completeness and acceptance Implementation related to fault correction EEcs 448 33 Dr Douglas Niehaus 2009 Inception Phase Emphasis of the inception phase is to determine whether it is worth developing the product and if so which set of possible features are most costeffective Two major steps of the requirements workflow Understand relevant components and product design issues in the domain Build a business model Questions that the Inception phase should answer ls proposed product costeffective Can proposed product be delivered on time What development risks eXist and how can they be mltlgated EEcs 448 35 Dr Douglas Niehaus 2009 Phases of Unified Process A Inception i Elaboration Etonstructioni Transition phase I phase I phase I phase Requirements 4 I workflow I g g I I I w I I g Anilfylsls y I y 439 war ow I I I c I I 9 Design g workllow I 1 I I Implementation workflow I I I I I I Test workflow I I I I Time Figure 31 EEcs 448 34 Dr Douglas Niehaus 2009 Inception Phase Risks should be classified and ranked Technical HW language capabilities Requirements omission or error Mitigated by care and review of req WF Architectural mistakes Mitigated by 00 and design for modification Ranking by combination of probability and probable level of cost pain Time and effort applied to risks in roughly descending order of cost Other workflows are also begun in Inception Phase EEcs 448 35 Dr Douglas Niehaus 2009 Inception Phase Inception Phase Analysis WorkFlow Collecting information relevant to product design Consider how requirements imply existence of certain product components and their properties Implementation WorkFlow Sometimes no coding Often proofofconcept for assumed implementation methods to test assumption validity and product feature feasibility Test WorkFlow Review of requirements for correctness and completeness EECS 44B 37 Dr Douglas Niehaus 2009 Inception Phase Planning is important in every phase Insufficient information at beginning of inception phase to plan the whole project Assertions and constraints can still be generated Planning for inception phase itself is important Documentation at every phase Inception Phase deliverables Initial versions of domain model business plan set of requirements artifacts tentative set of analysis artifacts tentative architecture list of risks set of use cases elaboration phase plan initial version of business case EECS 44B 38 Dr Douglas Niehaus 2009 Elaboration Phase Initial business case is overall aim of inception phase Assessment of whether building the product is a goodidea Revenue projections market estimates initial cost estimates For inhouse software this can also include an Initial costbenefit analysrs Many projects are assessed too optimistically at this phase but given all the unknowns excessive pessimism is also a significant risk You are often forced to make decisions with insufficient data Experience helps develop intuition EECS 44B 39 Dr Douglas Niehaus 2009 Aim of Elaboration Phase is to Refine requirements Refine analysis and corresponding architecture Complete proofofconcept implementations Rapid Prototypequot for customer review Feedback on feature integration lookanfeel Guide modification of design for construction Monitor risks lf greater understanding generally reduces perceived risk that is a good sign Refine business case Per featurecomponent as well as for product as a whole Produce a Software Project Management Plan SPMP EECS 44B 40 Dr Douglas Niehaus 2009 Elaboration Phase Construction Phase Deliverables include Completed domain model Completed business model Completed requirements artifacts Completed analysis artifacts Updated architecture Updated list of risks Software Project Management Plan SPMP Completed business case Rapid Prototype may come during or at end of this phase but earlier feedback is easier to integrate EECS 44B 41 Dr Douglas Niehaus 2009 Transition Phase Aim of the Construction Phase is produce the first operational quality version of the software Socalled Beta release Deliverables include Initial User s Manual All product components Beta version Completed architecture Updated risk list SPMP Updates to business plan if necessary EECS 44B 42 Dr Douglas Niehaus 2009 Semester Project Phases Aim of Transition Phase is to ensure the client s needs have been met Phase driven by feedback from beta testing Faults in software are corrected Manuals are completed Deliverables All product components Completed documents including product user and architecture manuals EECS 44B 43 Dr Douglas Niehaus 2009 As with all class assignments the semester project in this class is an approximation of reality for educational purposes Compromises and omissions made to Simplify details to make principles clearer Simplify implementation to fit within semester time constraints Semester project will use Inception Elaboration and Construction phases No time for Betatesting and no beta testers Minimal business plan Limited to simple costbenefit debate about difficulty of implementing some features vs their perceived utility EECS 44B 44 Dr Douglas Niehaus 2009 Semester Project Phases One vs Two Dimensional Models Feature set determination Should be based on a debate about perceived value of each feature vs perceived implementation cost Class wide Pergroup Essentially the questions should be Do we think this feature is feasible in the time available taking other features into account Do we think the feature is worth the effort Some features will be mandatory others included in dialogue between group and instructor More realistic experience in SWE process EEcs ME 45 Dr Douglas Mlenalls 2009 One vs Two Dimensional Models Classical lifecycle models are onedimensional Generally a single axis represents lifecycle Two dimensions better represent realistic process Unified process is current best practice axzqd enu hilllm h mulemmls omexB Requlremrnl phat v M w Analysis my phzxu wnlklluw Design Deggn quotlym wwkilaw lmplmmmm lmplemmauan pm wovkllau Phase Workllows lummml mm er El 1 EEcs ME 45 Dr Douglas Nlehans 2009 Improving Software Process Unified process ls best way to date to treat a large problem as a set of smaller largely independent problems Provides an explicit framework for incrementation and iteration Explicitly embraces the fact that a developer s understanding of a project improves as development proceeds Changes and refinements are inevitable because decisions are made with incomplete knowledge at several stages of project Handles inevitable changes and refinements relatively well and tries to explicitly support them EEcs ME 47 Dr Douglas Mlenalls 2009 Unified Process is currently the best approach It will be superseded by improved methods Software professionals are always looking for the next breakthrough Global economy is critically dependent on computers and hence on software animating them Governments of many countries concerned about software process reliability and productivity US Department of Defense has conducted many studies trying to improve software process Software Engineering Institute SEI at CMU founded and funded in response to concerns EEcs 445 Ala Dr Douglas Nlehans 2009 Improving Software Process Improving Software Process One major SEI success Capability Maturity Model CMM initiative Related software process improvement efforts ISO 9000series standards ISOIEC 15504 international initiative Involves more than 40 countries Capability Maturity Models Related group of strategies for improving process Regardless of lifecycle model used Maturity is a measure of how well the process being used works a metameasure CMMs software human managementsystem engineering integrated product development EECS 44B 49 Dr Douglas Niehaus 2009 Improving Software Process Software CMM incorporates both technical and managerial aspect of process Assumes New techniques not enough to improve process Management must be excellent as well Improvements will have to be made longterm and thus incrementally Five maturity levels defined ML1 initial level no sound SWE management ad hoc methods most actions in response to crisis Many of world SWE groups are at this level EECS 44B 50 Dr Douglas Niehaus 2009 Improving Software Process ML2 repeatable process level Basic SW project management practices Planning and management based on experience with similar projects Measures of some kind are taken Problems identified and addressed ML3 Defined Level SW production process fully documented Managerial and technical aspects clearly defined Reviews used to improve SW quality CASE tools to support process Many organizations have reached ML2 and ML3 EECS 44B 51 Dr Douglas Niehaus 2009 ML4 Managed Level Quality and productivity goals for projects Compliance continuously measured Corrective actions taken for deviations Statistical controls in place ML5 Optimizing Level Goal is continuous improvement of process Statistical quality and process control techniques Experience from one project used in future projects to support continuous improvement To improve organizations must first understand their current level and then identify desired new process EECS 44B 52 Dr Douglas Niehaus 2009 Improving Software Process Improving Software Process Figure 33 ms us 53 m Dough Nmkzvxez m Improving Software Process Long hard process to improve Advancing a level can take 15 a 3 years Advancing from ML1 to ML2 can take 3 to 5 years Often difficult to instill a methodological approach and mindset Romance of independent software developer can be strong EECS 448 and classes like it are designed to make students more receptive Requiring fewer hard lessons to dedicate themselves to an Improvtng process A wide range of other improvement initiatives exist msua s Drmughxknlzvxez m Software Process Difficulties Huge amounts of money are involved in large organizations and so even modest improvements in the process can reap large rewards Hughes Aircraft SWE Division estimated savings of 2 Million in moving from ML2 to ML3 Other positive experiences ML1 to ML3 doubled productivity returned 770 for every 100 invested in improvement Company using ISO 9000 and CMM Errors in effort estimation decreased from 50 to 15 Effectiveness of reviews 40 a 80 Project reworking effort 12 a 6 ms us 55 m Dough Nmkzvxez m Many aspects of software development are hard in their essence High level of inherent complexity in many products Need to make some decisions with incomplete information and improvement them later Changing nature of many target environments lmprecision of many clients Accidental complexit are those aspects added by current methods an which can thus in theony be eliminated by improved processes Complexity conformity changeability invisibility ms us 55 m Dough Nmkzvxez m Software Process Difficulties Complexity software products are more complex than any human creation in history Thus difficult to understand manage and maintain Conformity SW for system automation SW must conform to system being automated not the system to the SW Sometimes a misconception that SW is always the most flexible part of a design combining HW and SW Changeability Always pressure to change SW Often easier to change SW than any other component SW implements function so Afunction gt ASW EECS 44B 57 Dr Douglas Niehaus 2009 No Silver Bullet Phrase refers to an instantaneously effective solution Famous SWE Article title Fred Brooks IBM 370 project and the Mythical Man Month Book Well worth reading May be based on 1950 s Hollywood CMovie Werewolf disposal method metaphor You had to shoot them with a silver bullet Many candidates for SW breakthroughs have failed to solve all problems Highlevel languages Time Sharing SW development environments Proofs of correctness AII helped by solving some problems not all EECS 44B 59 Dr Douglas Niehaus 2009 Software Process Difficulties Invisibility SW is a virtual construct and cannot be visualized No acceptable way to represent a complete product No 3D models scale models or blueprints Individual developer s imaginations can be quite different in visualizing same product Communication among developers difficult Flowcharts UML Data Flow Diagrams Object Interaction Diagrams etc are all specific views of dirr felrent aspects of a product not the product as a w o e EECS 44B 58 Dr Douglas Niehaus 2009 Conclusions Software development is hard It will stay hard Awareness of software process and its difficulties is a first step in improving your own productivity and understand the efforts of various organizations Longterm commitment to continuous improvement is a key psychological step Learn to enjoy always trying to get better Suggestions for better productivity Use COTS SW not custombuilt when possible Rapid prototypes and proofofconcept designs Training and encouraging great designers Industry productivity improves 6 o per year EECS 44B 60 Dr Douglas Niehaus 2009