Dilbert Scott Adams. CSc 233 Spring PDF Free Download

Dilbert Scott Adams CSc 233 Spring 2012

Dilbert Scott Adams CSc 233 Spring 2012 2

Dilbert Scott Adams CSc 233 Spring 2012 3

prerequisites CSc 233 Spring 2012 I thought we had agreed long ago that the Department Policy was that all instructors would check for the completion of all prerequisites in the prerequisite chain. This may have been requested, but I don't recall it ever becoming policy. I don't check prerequisites. We are a 21st century computer science department at a university with an expensive CMS system. I would think that this is a university-wide problem and requires a university-wide solution that is better than having hundreds of faculty do such busy-work. 4

CSc 233 Spring 2012 How hard would it be for CMS to make a second prerequisite check after grades have been submitted but before the semester begins? A few hours work by a talented programmer should suffice, don't you think? A day in the life 5

Life Cycle: Chapter 3: Using Life Cycles The way you and the team organize the work of product development. When to define requirements, design, develop, and test, as well as concurrently. There is no one right way it depends. On what? 6

What process? Evidence shops that had no well-defined process were unable to deliver on-time with expected features. There is no Best Practice process. Necessary but not necessarily sufficient Every project is different, every team is unique the Project Manager decides what works & what does not. The methodology chosen should include periodic reevaluation and inclusion of practices that fit your project and your team. Ship It! A Practical Guide to Successful Software Projects. Richardson & Gwaltney. Pragmatic Bookshelf, 2005 7

Figure 3.1 Type Serial Iterative Incremental Iterative / Incremental Ad hoc Examples Waterfall, Phase gate Spiral, evolutionary prototyping Design to schedule, staged delivery Agile (such as Scrum, XP) Code & fix Strengths & necessary conditions for success Project Priorities Prognosis for success Manages cost risk. 1. Features set Successful with feedback Known and agreed upon 2. Low defects Well-understood system architecture 3. Time to release Requirements stable over the project Project team stable over the project Manages technical risk 1. Features set Successful assuming the Ever-evolving requirements 2. Low defects finishing parts are 3. Time to release and occur. Manages schedule risk. 1. Time to release Successful Can absorb small requirements 2. Low defects changes but not enough changes that 3. Feature set affect the architecture. Manages both schedule & technical risk 1. Time to release Successful Difficult to do well without a 2. Feature set integrated team. 3. Low defects You guys start coding; 1. Time to release Unsuccessful I ll get the requirements 2. Feature set 3. Low defects 8

Serial Figure 3.2 Requirements Analysis Design Code Integration Iterative Requirements Prototype: Analysis, Design, Code Prototype: Analysis, Design, Code Prototype: Analysis, Design, Code Integration Incremental Some Requirements Analysis to choose overall architecture Design, Code, Integrate & Design, Code, Integrate & Final Integration Final Agile Some requirements / Planning Repeat as needed Each timebox results in running tested features. 9

Serial Figure 3.2 CSc 233 Spring 2012 Requirements Analysis Design Code Integration Iterative Requirements Prototype: Analysis, Design, Code Prototype: Analysis, Design, Code Prototype: Analysis, Design, Code Integration Incremental Some Requirements Analysis to choose overall architecture Design, Code, Integrate & Design, Code, Integrate & Final Integration Final Agile Some requirements / Planning Repeat as needed Each timebox results in running tested features. 10

Serial Figure 3.2 CSc 233 Spring 2012 Requirements Analysis Design Code Integration Iterative Requirements Prototype: Analysis, Design, Code Prototype: Analysis, Design, Code Prototype: Analysis, Design, Code Integration Incremental Some Requirements Analysis to choose overall architecture Design, Code, Integrate & Design, Code, Integrate & Final Integration Final Agile Some requirements / Planning Completed features at the end of each iteration Repeat as needed Each timebox results in running tested features. 12

Combination: Iterative & Incremental Initial pass at requirements Prototype what we do know about. Get feedback. Select an architecture Fully implement 3 features, integrating as we go. architecture Demo what we have. Keep implementing, integrating as we go. Final test. Feedback needed: To assess remaining project risks To assess project s state To assess how quickly the team can produce working software The more you know, the better you can predict done. 13

CSc 233 Spring 2012 Incremental development Scheduling and staging strategy in which the various parts of the system are developed at different times or rates, and integrated as they are completed. It does not imply, require nor preclude iterative development or waterfall development - both of those are rework strategies. The alternative to incremental development is to develop the entire system with a "big bang" integration. 14

CSc 233 Spring 2012 Iterative development Rework scheduling strategy in which time is set aside to revise and improve parts of the system. It does not presuppose incremental development, but works very well with it. Typical difference is that the output from an increment is not necessarily subject to further refinement, and its testing or user feedback is not used as input for revising the plans or specifications of the successive increments. The output from an iteration is examined for modification, and especially for revising the targets of the successive iterations. 15

Fig 3.7 One Large Project Life Cycle Developer Life Cycle Prototype architecture and select product architecture Design, code, integrate and test features A, B, C: add to smoke tests were makes sense Design, code, integrate and test features D, E, F, G, H More stages of Design, code, integrate and test, including add more smoke tests Initial Definition of Requirements Select test architecture Develop whole product smoke tests Develop first pass of system tests to verify release criteria Develop system tests to test features A, B, C in more depth More iterations of adding more detailed system tests and adding more tests to verify release criteria Final integration Final test er Life Cycle 16

Feedback Design Debug Code 17

Code & Refactor Loop Start a feature Refactor Code Build at least daily 18

Waterfall CSc 233 Spring 2012 Agile 19

CSc 233 Spring 2012 Waterfall Project Team Agile Project Team 20

CSc 233 Spring 2012 Waterfall Project Scope Change Agile Project No Scope Change 21

Architectural Risk Risk is that the architecture will not work for all features. Why would the Waterfall life cycle be the riskiest for managing architectural risks? The only way to really manage architectural risk is to implement something and test it. 22

Stuck with a serial lifecycle! Plan to iterate on everything (planning, requirements & prototyping) Prototype and show your customer as much as possible as early as possible. Feedback!!! Integrate testing from the beginning work with the testers. Implement by feature, integrating and testing Documentation? Yes, but it s not the deliverable. 23

The author s favorite Life Cycle Agile is her first choice but!! If the customer is not readily available, If the team members are not into collaborating, If the team members are not disciplined, forget it! Regardless, staged delivery is recommended. Finished features get pushed out as soon as possible. 24

Dilbert Scott Adams. CSc 233 Spring 2012