SE 430 Object Oriented Modeling

1. SE 430 Object Oriented Modeling Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 428 Office Hours: Thursday, 4:00 – 5:30 SE 430: Lecture 10

2. Administrivia • Comments and feedback • Last Assignments • Assignment 7 • Due tonight • Assignment Critique • Due November 17, 2016 • Term Project • Due November 17, 2016 • Final Examination • November 12 to November 18. • Given on Desire2Learn • See study guide on-line SE 430: Lecture 10

3. Team Project • The final report should use standard business report format. • Due date: Thursday,November 17, 2016 • Use D2L to submit. I need only one copy from the team! • The document should be reasonably smooth and coherent. • Cut and paste doesn’t always work well. Different styles and formats are jarring. Have a logical organization. • Proofread your submission: • Spelling • Print it out and check format and layout • Names and identifiers are spelled consistently • All team members should read the entire submission. • Remember your grade depends on how good the submission is. • Questions • What to do about Design Class Diagram if it is too big • Group (peer) evaluations due at the same time: use email SE 430: Lecture 10

4. Peer review • See instructions on http://condor.depaul.edu/dmumaugh/se430/assignments/rating.html • Each student must review the other team members and rank them on their performance. • This is the place for team members to talk about members who did not contribute or contributed poor work, etc. • I use this to adjust the team project grades. • I give a grade for the project and then adjust the individual contributors accordingly. • It is possible for a person to get a very low score if they have not contributed or did and required total rewriting by other team members. • Send me an email directlywith your comments. See details on web page. • Due same time as project SE 430: Lecture 10

5. Things to Ponder • Some people don’t read the book or notes or spend time on the lectures • Some skip over the administrivia and then wonder why they weren’t told things. • Some anecdotal evidence that people who skip classes tend to do worse on exams. • Some don't read the descriptions thoroughly. • Some do not follow instructions; explicit instructions • Some solve problems not requested to be solved; systems not within the scope of the problem. • Engineering is a precise discipline and uses the written word to describe things concisely. • Terminology is important. SE 430: Lecture 10

6. SE 430 – Class 10 Topic: Wrap-up: • Overview of Systems Development Life Cycle Methodologies • Sequential Methodologies • Evolutionary Methodologies • Agile Methodologies • Best practices • Review Reading: • Arlow & Neustadt, Ch.'s 1, 2, 10 • Scrum Primer (all) • The New Methodology (Martin Fowler) • Important Object Oriented Concepts, Lecture 1, Slides 32-70 • Software Development Life Cycle, Lecture 1, Slides 71-88 SE 430: Lecture 10

7. Thought for the Day “It doesn’t matter what process you use as long as you use one, and you follow it fully.” - James Coplien SE 430: Lecture 10

8. Last time Topics: • Design Model • Design Model in the UP • Constructing Design Class Diagrams • Package and Deployment Diagrams • Non-Graphical Design Model Documentation • Architecture • Architectural Patterns • Architectural Patterns for the Assemble Document System SE 430: Lecture 10

9. Cleanup – After the DCD • Use scenarios to validate the responsibilities of each object. • Check the interaction diagram for each scenario to check the completeness of the validation. • Take each use case and trace its actions on the Design Class Diagram • Use this to validate associations and other items • Make sure terminology and names are consistent and included in Glossary SE 430: Lecture 10

10. Overview of Systems Development Life Cycle Methodologies SE 430: Lecture 10

11. The systems development lifecycle • “The systems development life cycle (SDLC) is the process of understanding how an information system (IS) can support business needs by designing a system, building it, and delivering it to users”* • A methodology is a formalized approach to implementing the SDLC • What differentiates one methodology from another: • The specific activities that must be performed • When, how, and how often the activities are performed • Who performs the activities • The amount of emphasis placed on an activity at a specific point in time * Dennis, Alan (2012-05-01). Systems Analysis and Design with UML, 4th Edition (Page 2). Wiley. Kindle Edition. SE 430: Lecture 10

12. Software Development Process Ad hoc Code and Fix Rapid Prototyping Prescriptive Linear/sequential (Classic and Waterfall) Evolutionary (Iterative/incremental or spiral) Unified Process Adaptive Lean and agile methods SE 430: Lecture 10

13. Sequential Methodologies SE 430: Lecture 10

14. Sequential (‘waterfall’) methodology • The term waterfall was coined by Winston Royce in a 1970 paper titled Managing the Development of Large Software Systems, in the Proceedings of IEEE WESCON • The paper used the sequential waterfall approach as an example of an ill-conceived, risk-prone practice for developing large systems • Royce advocated a series of iterative feedback loops among the development stages, incrementally gaining learning value from working software • Instead of adopting the approach Royce advocated, managers and practitioners adopted its anti-form, without feedback loops SE 430: Lecture 10

15. Waterfall SDLC • Each phase is marked by completion of Deliverables • The primary software project phases: • Requirements • Analysis • Design • Construction • Quality Assurance (aka Testing) • Deployment SE 430: Lecture 10

16. Waterfall SDLC SE 430: Lecture 10

17. Waterfall system development model • Highly-sequential process • Failure symptoms: • Protracted integration and late design breakage • Late risk resolution • Requirements-driven functional decomposition • Adversarial stakeholder relationships • Focus on documents and review meetings • Still followed (in name or practice) by many organizations, usually a modified version SE 430: Lecture 10

18. Waterfall system development model Sequential: suitable projects and management approaches • A sequential SDLC is suitable for projects with: • Clear, unambiguous, and stable user requirements • Familiar, proven technology • Low complexity • Adequate time • Stable schedule • A project meeting most of these criteria can use conventional project management practices, such as big, up-front planning and conventional risk assessment SE 430: Lecture 10

19. Evolutionary methodologies SE 430: Lecture 10

20. Evolutionary Model (Spiral) • Software is developed in a series of incremental releases ranging from early prototypes to complete engineered versions of the system. • Characterized by • Risk driven approach • Milestones • Weaknesses • Convincing customers that evolutionary approach is controllable. • Demands expertise in risk assessment. • Strengths • Matches the natural progression of a project. • Reduces risk SE 430: Lecture 10

21. Evolutionary methodologies • An evolutionary methodology follows an iterative and incremental approach that allows the start of development with incomplete, imperfect knowledge • An iterative and incremental process is like solving a jigsaw puzzle: neither top-down nor bottom-up but accretionary and convergent • An iterative and incremental process offers these advantages: • Logical progress toward evolving a robust architecture • Effective management of changing requirements • Effective means to address changes in planning • Ability to perform continuous integration • Early understanding of the system (the ‘Hello world!’ effect) • Ongoing risk assessment • Evolutionary methodologies are incremental at both the macro (project- scale) and micro (working team) process levels SE 430: Lecture 10

22. Iterative Development Iterative Development Successive enlargement and refinement of a system through multiple development cycles of analysis, design, implementation and testing. Spiral Model Developed by Barry Boehm at TRW in 1988 Incorporates risk management as an integral part of the life cycle Prior to every major phase, risks are identified and analyzed, and steps are taken to avert them If progress is not adequate, the project may be abandoned SE 430: Lecture 10

23. Iterative Development SE 430: Lecture 10

24. Iterative system development model • Non-linear approach to system development • Incorporates top five principles of modern development processes: • Architecture first. Provides the central design element • Iterative life-cycle process. Provides the essential risk management element • Component-based development. Provides the technology element • Change management environment. Provides the control element • Round-trip engineering. Provides the automation element SE 430: Lecture 10

25. 5,000 foot view of Iterative SDLC • Iterative SD model defines four life-cycle phases: • Inception • Elaboration • Construction • Transition • We iterate through each phase, and repeat as needed. • Now, for a quick survey of the phases… SE 430: Lecture 10

26. Inception phase • Essential activities • Formulate product scope. Capture requirements and operational concept • Perform feasibility analysis. Determine whether the organization has the resources and technical capabilities to meet customer's needs • Synthesize the system architecture. Evaluate essential system design constraints and trade-offs, as well as available solutions • Plan and prepare business case. Address risk management, staffing, iteration plans, cost, and infrastructure SE 430: Lecture 10

27. Elaboration phase • Most critical phase of the four • Essential activities • Elaborate the vision. Detail elements of the vision that drive architectural or planning decisions • Elaborate the process and infrastructure. The construction process and environment are established here • Elaborate the architecture and select reusable (internal or COTS) components. Baseline the architecture as quickly as possible and demonstrate that the architecture will support the vision at reasonable cost in reasonable time SE 430: Lecture 10

28. Construction phase • Essential activities • Achieve useful versions (intermediate, alpha, beta, and other test releases) • Perform resource management, control, and process optimization • Complete component development and test • Assess product releases against acceptance criteria SE 430: Lecture 10

29. Transition phase • Essential activities • Perform deployment-specific engineering tasks. Commercial packaging and production, sales kit development, field personnel training • Assess deployment baselines against complete vision and acceptance criteria. Examine and compare what is being delivered to what was envisioned and delineated by acceptance criteria • Plan for next iteration SE 430: Lecture 10

30. Suitable Projects And Management Approaches • An evolutionary SDLC is suitable for projects with: • Reasonably–but not perfectly–clear user requirements • Unfamiliar or unproven technology • High complexity • Short time schedule • Schedule variability • Such a project would use rolling wave planning rather than big, up-front planning and use a continuous, adaptive approach to risk assessment and management SE 430: Lecture 10

31. Agile Methodologies SE 430: Lecture 10

32. Agile Modeling SE 430: Lecture 10

33. New Modeling Paradigms The New Methodology, (Martin Fowler) http://www.martinfowler.com/articles/newMethodology.html • The Manifesto for Agile Software Development • XP (Extreme Programming) • Lean Programming • Cockburn's Crystal Family • Open Source • Feature Driven Development • Scrum • DSDM (Dynamic System Development Method) • Context Driven Testing aka Test Driven Development SE 430: Lecture 10

34. The Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactionsover processes and tools • Working softwareover comprehensive documentation • Customer collaborationover contract negotiation • Responding to changeover following a plan That is, while there is value in the items on the right, we value the items on the left more.” Kent Beck et al http://www.agilemanifesto.org SE 430: Lecture 10

35. Agile • The word ‘agile’ has become closely associated with specific forms of agile development, such as Extreme Programming (XP) and Scrum • In fact, agility spans a broad spectrum that now extends well beyond these specific forms and encompasses various hybrid approaches • The core aspects of agility include: • Rapid and productive response to change • Rapid re-prioritization of resource use • Rapid response to market changes, risks, and opportunities • Use of incremental and iterative development processes • Use of just-enough and just-in-time principles • Agile principles and practices have, in fact, spread far beyond their software roots SE 430: Lecture 10

36. Agile Projects • An agile project is completed in small sections called iterations, or in scrum, sprints. • Each iteration is reviewed and critiqued by the project team, which may include representatives of the client business as well as employees. • Insights gained from the critique of an iteration are used to determine what the next step should be in the project. • Each project iteration is typically scheduled to be completed within two weeks. SE 430: Lecture 10

37. Agile Modeling • Agile development is a response to the problems of traditional "heavyweight" software development processes • Too many artifacts • Too much documentation • Inflexible plans • Late, over budget and buggy software • Process has to be lightweight and sufficient • Lightweight helps us adapt and move • Sufficient recognizes our ineffectiveness to be complete and relies on strong communication SE 430: Lecture 10

38. Agile Modeling • Originally proposed by Scott Ambler • Suggests a set of agile modeling principles • Model with a purpose • Use multiple models • Travel light • Content is more important than representation • Know the models and the tools you use to create them • Adapt locally SE 430: Lecture 10

39. An Agile Process • Is driven by customer descriptions of what is required (scenarios) – user stories • Recognizes that plans are short-lived • Develops software iteratively with a heavy emphasis on construction activities • Delivers multiple ‘software increments’ • Adapts as changes occur SE 430: Lecture 10

40. Agile Development Process Iterative and evolutionary development • Adaptive planning • Incremental delivery • Timeboxing • Set amount of time for iteration • Adapt future iteration based on the realities • Agility • More focused on success than sticking with a plan • Working software is valued and considered measure of progress SE 430: Lecture 10

41. What is “Agility”? • Effective (rapid and adaptive) response to change • Effective communication among all stakeholders • Drawing the customer onto the team • Organizing a team so that it is in control of the work performed Yielding … • Rapid, incremental delivery of software SE 430: Lecture 10

42. Agile Modeling • “User Stories” - informal use cases • CRC Cards • Use UML as appropriate: • Activity diagrams • Interaction diagrams • Class diagrams • Minimalist philosophy SE 430: Lecture 10

43. User Stories User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement. User stories are the Agile equivalent of Use Cases SE 430: Lecture 10

44. Methodologies Methodologies share common principles, but differ in practices • Lean Programming • eXtreme Programming (XP) • Scrum SE 430: Lecture 10

45. Scrum http://en.wikipedia.org/wiki/Image:Rugby_union_scrummage.jpg http://www.controlchaos.com SE 430: Lecture 10

46. Scrum • Developed by Ken Schwaber and Jeff Sutherland • Name derived from Rugby • Group effort to move quickly to counter the opposite team, adjusting the move along progress • Divides a project into iterations (sprints) of 30 days • Sprint – 30 days iteration cycle with pre-sprint and post-sprint activities • Define functionality for sprint • Leave team alone to deliver • Sprint Goal – minimum success criterion to steer and keep focus SE 430: Lecture 10

47. Scrum 1From: Deemer et al., The Scrum Primer v2.0, 2012 • Scrum is a “a development framework in which cross-functional teams develop products or projects in an iterative, incremental manner. ”1 • Scrum focuses on defining the boundaries of the software development process rather than on specifying practice details • Because of its less-prescriptive nature, Scrum has been well-received in organizations transitioning from plan-driven to more agile processes • In fact, Scrum can be adapted readily to non-software projects, as well, such as product development and advertising campaigns • Note: ‘Scrum’ is not an acronym SE 430: Lecture 10

48. Scrum • Scrum iterations are called sprints and last no more than one month • Sprints are time-boxed: they are never extended, but may be restarted • Scrum defines three roles: • The product owneris responsible for managing the product feature list • The team does the work • The scrum masterfacilitates the scrum process; the scrum master is not a ‘conventional’ project manager • Scrum produces an executable, potentially shippable product increment at the end of each sprint • Potentially shippable means ‘done’ in the scrum sense: all commitments for the sprint have been met–no “it's 80% done” is allowed • This demonstrates value iteratively to the product owner and to other stakeholders SE 430: Lecture 10

49. The Sprint Cycle Planning meeting at the start of the sprint During the sprint, team members attend a daily Scrum meeting, At the end of the sprint, there is a sprint review At the end of each sprint is the sprint retrospective. SE 430: Lecture 10

50. The Sprint • Planning meeting at the start of the sprint • create a sprint backlog – a list of the tasks to perform during the sprint. • During the sprint, the team takes a small set of features from idea to coded and tested functionality. • At the end, these features are done, meaning coded, tested and integrated into the evolving product or system. SE 430: Lecture 10