Published on

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • When I was a team lead, I would double the estimates from my programmers. The Project Manager would double my estimates and we would be just about right.
  • During the legislative session, the Division director/program managers are addressing bills, responding to questions, etc. They are working 60+ hour weeks. When the session is over, they take vacation. This is a challenging when you need decisions made. Inadequate participation: getting senior social workers to get involved when they are spread so thin.
  • Predetermined schedules.
  • Right decision makers: Commissioner Steering Committee Division director Are decisions reversible, consistent? Management commitment: Retirements Change in management: (in 6 years, I worked with) 5 Commissioners 5 Family Services Directors 2 CFOs 1 New COO 1 New Strategic Planning Director Change in Business Strategy: What is today’s priority? User commitment: I am happy with what I know
  • There will always be new and changed risks/issues during a project.
  • Steering Committee: What do you need? How can we help? Examples: Co-locate the development team to improve communications Business Analyst certification (both functional and technical)
  • Change is the second leading cause of software failures. Each proposed change should have an attached cost/benefit document as well as a schedule and impact analysis.
  • Virginia: Contrast: One county that has 4 office buildings to a county that has 6 workers in a mobile trailer. Relationships: Relationships between the project technical and the project functional team Relationships between the team and the project sponsor Relationships between the team and the Steering committee Positive Informal: Using informal relationships can help get support, clarify issues quickly (ie call a colleague/stop by the colleague’s cube) Negative informal: Support desk - bypassing formal reporting methods leads to lack of a complete problem picture Common Vision: We are all working to accomplish a single vision
  • Virginia has a performance budget process: Each program has 3-4 measures that are supported by budget: personnel systems Quarterly updates to the Governor’s office
  • Advantages: End result, cost avoidance/cost reduction
  • Trend Analysis: Business (Business Strategy) Information needs (ie Chaffee) Applications (in support of business needs) Technology (ie Digital pen) Virginia: No more new MAPPER development Moving off the UNISYS mainframe
  • Sub Division Example: 2 acre family lots: Street View Lighting View Sewer View Water View What if you change to 1 acre family lots? Impact on streets, lighting, sewer, water, etc.
  • Zachman: What How Where Who When Why
  • Common understanding
  • Development Model: Enterprise options/constraints Development approach/tools Security
  • Audit trails: Common information gathering Common reporting
  • This example reflects adding a client from a match found during the search process.
  • Therese are the key quality attributes to be considered in system design. They were covered in Section 4. Additional comments? Scalability: 100, 1,000, 10,000? Re-usability Modular components Secure: Meets State’s Security requirements Meets Agency’s security requirements Able to withstand hostile attacks Disaster Recovery
  • (PowerPoint)

    1. 1. Course Topics 5-1 No. Topic 1 Course Introduction 2 Setting the Stage for Effective Systems Design 3 Key Components of Effective Systems Design 4 Building Quality into Systems Design 5 Overview of Systems Design Management, Approaches, and Products 6 Automating Systems Design 7 Challenge Exercise 8 Conclusion
    2. 2. Topic Objectives <ul><li>By the end of this topic, you should be able to: </li></ul><ul><li>Describe systems design management concerns </li></ul><ul><li>Describe the difference between Enterprise Architecture and Systems Architecture </li></ul><ul><li>Describe systems design considerations </li></ul><ul><li>Describe systems design approaches </li></ul><ul><li>Identify systems design artifacts </li></ul>5-2
    3. 3. Topic Outline <ul><li>Systems design management concerns </li></ul><ul><li>Enterprise Architecture </li></ul><ul><li>Systems Architecture </li></ul><ul><li>Systems design considerations </li></ul><ul><li>Systems design approaches </li></ul><ul><li>Systems design deliverables </li></ul>5-3
    4. 4. <ul><li>Why does it take so long? </li></ul><ul><li>Why does it cost so much? </li></ul><ul><li>Why does it have errors? </li></ul><ul><ul><li>Research shows that 60% to 80% of system errors are present in the design before coding begins </li></ul></ul><ul><li>Why doesn’t it meet my needs? </li></ul><ul><ul><li>“That’s what I said, but that’s not what I meant.” </li></ul></ul> Management Concerns 5-4 Source: Center for Business and Technology. Overland Park, Kansas, 2006. http://www.centerforbusiness.org
    5. 5. Possible Reasons <ul><li>Miscommunication </li></ul><ul><ul><li>Developers do not understand what is needed </li></ul></ul><ul><ul><li>Users are not really sure of what they want </li></ul></ul><ul><ul><li>Users have erroneous expectations </li></ul></ul><ul><li>Unrealistic schedules </li></ul><ul><ul><li>Poor or optimistic estimation </li></ul></ul>5-5
    6. 6. Possible Reasons, cont. <ul><li>Recruiting staff with appropriate skills </li></ul><ul><li>Access to experienced staff when needed </li></ul><ul><li>Inadequate participation by experienced end users </li></ul><ul><ul><ul><li>Inadequate design processes </li></ul></ul></ul><ul><ul><ul><li>Lack of appropriate design tools </li></ul></ul></ul><ul><ul><ul><li>Funding reduced or reallocated </li></ul></ul></ul><ul><ul><ul><li>Change in priorities </li></ul></ul></ul>5-6
    7. 7. Common Threads <ul><li>Common threads throughout any project </li></ul><ul><ul><li>Risk management </li></ul></ul><ul><ul><li>Change control </li></ul></ul><ul><ul><li>Managing user expectations </li></ul></ul><ul><ul><li>Communications </li></ul></ul>5-7
    8. 8. Risk Management: Risk Types <ul><li>Project </li></ul><ul><ul><li>Unclear system requirements </li></ul></ul><ul><ul><li>Budget </li></ul></ul><ul><ul><li>Schedule </li></ul></ul><ul><ul><li>Adequate staffing </li></ul></ul><ul><ul><li>Team turnover </li></ul></ul><ul><ul><li>Team skill level </li></ul></ul><ul><li>Technical </li></ul><ul><ul><li>Change in technologies </li></ul></ul><ul><ul><li>State/Department technical constraints </li></ul></ul>5-8
    9. 9. Risk Management: Types, cont. <ul><li>Business </li></ul><ul><ul><li>Right decision makers </li></ul></ul><ul><ul><li>Lack of management commitment </li></ul></ul><ul><ul><li>Change in management personnel </li></ul></ul><ul><ul><li>Change in management business strategy </li></ul></ul><ul><ul><li>Change in policy </li></ul></ul><ul><ul><li>Lack of user commitment </li></ul></ul>5-9
    10. 10. Risk Management: Methodology <ul><li>Risk management is a systematic process of &quot;identifying, analyzing and responding to project risk&quot; and then taking steps necessary to reduce the risk to an acceptable level. </li></ul>5-10 Source: Project Management Institute (PMI) PMBOK ® Guide . www.pmi.org
    11. 11. Risk Management: Why <ul><li>Increases the probability of project success </li></ul><ul><li>Prevents surprises </li></ul><ul><li>Assists in meeting deadlines </li></ul><ul><li>Controls costs </li></ul>5-11
    12. 12. Risk Management: Processes <ul><li>Risk identification </li></ul><ul><li>Risk assessment </li></ul><ul><li>Risk evaluation </li></ul><ul><li>Mitigation planning </li></ul><ul><li>Risk control </li></ul><ul><li>Risk reporting </li></ul>5-12
    13. 13. Risk Management: More Info <ul><li>Risk Management for Child Welfare Information Systems - Online Training Course </li></ul><ul><li>See References/Reading List for more information </li></ul>5-13 On-line Courses. http://www.state-itc.org/cw_resources.html Reading List: “Making Smart IT Choices: Understanding Value and Risk in Government IT Investments.” University at Albany, State University of New York, Center for Technology in Government. Sharon S. Dawes, Theresa A. Pardo, Stephanie Simon, Anthony M. Cresswell, Mark F. LaVigne, David F. Andersen, and Peter A. Bloniarz. April, 2004. http://www.ctg.albany.edu/publications/guides/smartit2
    14. 14. Change Control: Processes <ul><li>Identify change </li></ul><ul><li>Control change </li></ul><ul><li>Change is properly implemented </li></ul><ul><li>Report changes to others </li></ul>5-14
    15. 15. Managing User Expectations <ul><li>Under Promise and Over Deliver </li></ul><ul><li>See References/Reading List for more information </li></ul>5-15 Reading List: “Managing User Expectations.” Michael Leicht and Dr.Vicki Sauter, University of Missouri at St. Louis. November 29, 1999. http://www.umsl.edu/~sauterv/analysis/user_expectations.html
    16. 16. Communications <ul><li>Communicate, communicate, communicate </li></ul><ul><ul><li>Issues </li></ul></ul><ul><ul><li>Risks </li></ul></ul><ul><ul><li>Budget </li></ul></ul><ul><ul><li>Schedule </li></ul></ul><ul><li>Who </li></ul><ul><ul><li>Project Sponsor, Steering Committees, Commissioner </li></ul></ul>5-16
    17. 17. Relationships <ul><li>Regardless of the type of project, IT or otherwise, relationships with the project team and stakeholders can make or break the possibilities for success </li></ul>5-17
    18. 18. Topic Outline <ul><li>Systems design management concerns </li></ul><ul><li>Enterprise Architecture </li></ul><ul><li>Systems Architecture </li></ul><ul><li>Systems design considerations </li></ul><ul><li>Systems design approaches </li></ul><ul><li>Systems design deliverables </li></ul>5-18
    19. 19. Enterprise Architecture: Definition <ul><li>Current and future structure and behavior of an organization’s processes, information systems and personnel are aligned with the organization’s goals and strategic direction </li></ul>5-19 Source: Wikipedia – Enterprise Architecture. http://en.wikipedia.org/wiki/Enterprise_architecture
    20. 20. Enterprise Architecture: Components <ul><ul><ul><ul><li>E </li></ul></ul></ul></ul>5-20 Business Architecture Technology Architecture Information Technology Strategies Goals Processes Personnel Applications Interfaces Hardware Networks Security DATA Conceptual Logical Physical
    21. 21. Enterprise Architecture, cont. <ul><li>Enterprise Architecture includes the explicit relationship among these components: </li></ul><ul><ul><li>Business strategies </li></ul></ul><ul><ul><li>Business processes </li></ul></ul><ul><ul><li>Organization charts </li></ul></ul><ul><ul><li>System and interface diagrams </li></ul></ul><ul><ul><li>Technical inventories </li></ul></ul><ul><ul><li>Network topologies </li></ul></ul>5-21
    22. 22. Enterprise Architecture, cont. <ul><li>Advantages </li></ul><ul><ul><li>Reusability </li></ul></ul><ul><ul><li>Efficiency </li></ul></ul><ul><ul><li>Consistency 1 </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>Web Standards, Policies and Guidelines </li></ul></ul><ul><ul><li>Access to a central database </li></ul></ul><ul><ul><ul><ul><li>CIOs are looking to standardize on one integrated platform for information management 2 </li></ul></ul></ul></ul>5-22 Sources: 1 Daniel, Diann. The Rising Importance of the Enterprise Architect. CIO. March 31, 2007. http://www.cio.com/article/101401/The_Rising_Importance_of_the_Enterprise_Architect 2 CIO2CIO Reports. Information Management. http://www.cio2cioreports.com/
    23. 23. Enterprise Architecture Example 5-23
    24. 24. Enterprise Architecture Example, cont. 5-24
    25. 25. Enterprise Architecture Example, cont. <ul><li>Example 5.1, Commonwealth of VA Enterprise Architecture </li></ul>5-25 Example 5.1
    26. 26. Enterprise Architecture Framework <ul><li>Frameworks are commonly used to organize enterprise architecture into different views </li></ul><ul><ul><li>Example 5.2, Architectural Frameworks Examples </li></ul></ul>5-26 Example 5.2
    27. 27. Enterprise Architecture Framework, cont. <ul><li>More Information </li></ul><ul><ul><li>“ Concepts of Framework for Enterprise Architecture: Background, Description and Utility,” by John Zachman </li></ul></ul>5-27 Source: Zachman, John A. “Concepts of Framework for Enterprise Architecture: Background, Description, and Utility.” © 1993-1997. http://apps.adcom.uci.edu/EnterpriseArch/Zachman/zachman3_files/zachman3.htm
    28. 28. Service-Oriented Architecture (SOA) <ul><li>What is SOA? </li></ul><ul><ul><li>A collection of services </li></ul></ul><ul><ul><li>More technically, an application architecture in which functions are exposed as independent services </li></ul></ul><ul><li>What is a business service? </li></ul><ul><ul><li>A single-purpose business function that is translated to technology which is reusable and accessible by any application on any platform with the appropriate permissions </li></ul></ul>5-28
    29. 29. Service-Oriented Architecture Example: Common Client ID <ul><ul><li>BEFORE </li></ul></ul><ul><ul><li>AFTER </li></ul></ul>5-29 Child Support Child Welfare TANF Client ID Client ID Client ID Child Support Child Welfare TANF Common Client ID Service
    30. 30. Service-Oriented Architecture, cont. <ul><li>SOA is not </li></ul><ul><ul><li>A formal methodology for service description </li></ul></ul><ul><ul><li>Dependent on any development language </li></ul></ul><ul><ul><li>Dependent on web-services technology 1 </li></ul></ul><ul><li>It is one possible tool at an enterprise architect’s disposal 2 </li></ul><ul><li>Sources: </li></ul><ul><li>1 District of Columbia Case Study in Service-Oriented Architecture </li></ul><ul><li>http://www.state-itc.org/ntc2007/accessible/NTC2007-BELL_BIRDSONG-DELOITTE_DC/800x600/slide1.html </li></ul><ul><li>2 Daniel, Diann. The Rising Importance of the Enterprise Architect. CIO. March 31, 2007. http://www.cio.com/article/101401/The_Rising_Importance_of_the_Enterprise_Architect </li></ul>5-30
    31. 31. Service-Oriented Architecture, cont. <ul><li>More Information </li></ul><ul><ul><li>SOA Overview and Guide to SOA Research 1 </li></ul></ul><ul><ul><li>Twelve Common SOA Mistakes and How to Avoid Them 2 </li></ul></ul><ul><ul><li>Sources: </li></ul></ul><ul><ul><li>1 Abrams, Charles, and Shulte, Roy W. 3 January 2008. Gartner Research. www.gartner.com </li></ul></ul><ul><ul><li>[Registration required. Summary available at no charge. Full document requires subscription.] </li></ul></ul><ul><ul><li>2 Natis, Yefim V. and Pessini, Massimo. 26 October 2007. Gartner Research. www.gartner.com </li></ul></ul><ul><ul><li>[Registration required. Summary available at no charge. Full document requires subscription.] </li></ul></ul>5-31
    32. 32. Topic Outline <ul><li>Systems design management concerns </li></ul><ul><li>Enterprise Architecture </li></ul><ul><li>Systems Architecture </li></ul><ul><li>Systems design considerations </li></ul><ul><li>Systems design approaches </li></ul><ul><li>Systems design deliverables </li></ul>5-32
    33. 33. Systems Architecture: Definition <ul><li>An architectural model whose primary concern is to illustrate a specific set of tradeoffs inherent in the structure and design of a system </li></ul>5-33 Source: http://en.wikipedia.org/wiki/Software_Architectural_Model
    34. 34. Systems Architecture: Models <ul><li>Architecture model </li></ul><ul><li>Component-level model </li></ul><ul><li>User interface model </li></ul>5-34
    35. 35. Architecture Model <ul><li>Organization of programs (modules, objects) </li></ul><ul><li>How programs interact </li></ul><ul><li>Structure of data used by the programs </li></ul><ul><li>Development Model </li></ul>5-35
    36. 36. Software Component Definitions <ul><li>A software component is a self-contained building block that encapsulates both data and processing that is applied to the data </li></ul><ul><li>A nearly independent and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture </li></ul>5-36 Source: Brown, A. W. and K. C. Wallnan. Engineering of Component-Based Systems. Proceedings of the 2nd IEEE International Conference on Engineering of Complex Computer Systems (ICECCS '96) .
    37. 37. Component-Level Model <ul><li>Functionally independent </li></ul><ul><li>Re-useable (stored in a Library) </li></ul><ul><ul><li>Screen presentation, Navigation </li></ul></ul><ul><ul><li>Menu bars </li></ul></ul><ul><ul><li>Help </li></ul></ul><ul><ul><li>Printing </li></ul></ul><ul><ul><li>Audit trails </li></ul></ul><ul><ul><li>Security access levels: who, how </li></ul></ul><ul><ul><li>Single Sign on </li></ul></ul>5-37
    38. 38. User Interface Model <ul><li>User Interface </li></ul><ul><ul><li>The design of interfaces between software components </li></ul></ul><ul><li>External interface to other systems </li></ul><ul><li>Design of the interface between a human and the computer </li></ul>5-38
    39. 39. Systems Architecture, cont. <ul><li>IEEE 1016 Systems Architecture document </li></ul><ul><ul><li>Introduction </li></ul></ul><ul><ul><ul><li>Design overview </li></ul></ul></ul><ul><ul><ul><li>Requirements traceability matrix </li></ul></ul></ul><ul><ul><li>Systems Architectural Design </li></ul></ul><ul><ul><ul><li>Chosen systems architecture </li></ul></ul></ul><ul><ul><ul><li>Discussion of alternative designs </li></ul></ul></ul><ul><ul><ul><li>System interface description </li></ul></ul></ul>5-39 <ul><li>Source: IEEE 1016-1998, also known as the 1016 Standard for Software Design Description, is an IEEE standard that specifies the form of the document used to specify systems architecture and application design in a software related project. http://www.ieee.org </li></ul>
    40. 40. Systems Architecture, cont. <ul><ul><li>Detailed Description of Components </li></ul></ul><ul><ul><ul><li>Component n </li></ul></ul></ul><ul><ul><ul><li>Component n+1 </li></ul></ul></ul><ul><ul><li>User Interface Design </li></ul></ul><ul><ul><ul><li>Description of the user interface </li></ul></ul></ul><ul><ul><ul><ul><li>Screen image </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Objects and actions </li></ul></ul></ul></ul>5-40
    41. 41. Topic Outline <ul><li>Systems design management concerns </li></ul><ul><li>Enterprise Architecture </li></ul><ul><li>Systems Architecture </li></ul><ul><li>Systems design considerations </li></ul><ul><li>Systems design approaches </li></ul><ul><li>Systems design deliverables </li></ul>5-41
    42. 42. Systems Design Considerations <ul><li>Meet the needs and provide value to the customer </li></ul><ul><li>Design should be traceable to the requirements </li></ul><ul><li>Always consider the architecture of the system </li></ul><ul><li>Design should always begin with the data </li></ul>5-42
    43. 43. Data <ul><li>Goal of the organization is to enable the business to use information effectively </li></ul><ul><li>Data design is an essential element of architectural design </li></ul><ul><ul><li>Helps to simplify program flow </li></ul></ul><ul><ul><li>Makes design and implementation of components easier </li></ul></ul><ul><ul><li>Makes processing more efficient </li></ul></ul>5-43
    44. 44. Systems Design Considerations, cont. <ul><li>Use solid requirements </li></ul><ul><ul><li>Clear, complete, detailed, attainable, testable </li></ul></ul><ul><li>Plan realistic schedules </li></ul><ul><ul><li>Adequate time for planning, design, testing, bug fixes, retesting, changes and documentation </li></ul></ul><ul><li>Stick to initial requirements to the extent possible </li></ul><ul><ul><li>Defend against excessive change requests </li></ul></ul>5-44
    45. 45. Systems Design Considerations, cont. <ul><li>Establish and require frequent communications in multiple formats </li></ul><ul><ul><li>Formal inspections </li></ul></ul><ul><ul><li>Walkthroughs </li></ul></ul><ul><ul><li>Accessible documentation </li></ul></ul><ul><ul><li>Meeting minutes </li></ul></ul><ul><ul><ul><li>Fully document decisions </li></ul></ul></ul><ul><ul><li>Demos </li></ul></ul>5-45
    46. 46. Systems Design Considerations, cont. <ul><li>Collaboration </li></ul><ul><ul><li>Joint Application Development (JAD) </li></ul></ul><ul><ul><ul><li>Representative cross-section of users </li></ul></ul></ul><ul><ul><ul><li>Consensus list </li></ul></ul></ul><ul><ul><ul><ul><li>Objectives </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Services/Functions </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Constraints </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Performance criteria </li></ul></ul></ul></ul><ul><ul><ul><li>Use cases </li></ul></ul></ul><ul><ul><ul><ul><li>How the system will be used </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Use cases drive analysis and modeling activities </li></ul></ul></ul></ul>5-46
    47. 47. Systems Design Considerations, cont. <ul><li>Prototyping </li></ul><ul><ul><li>Higher acceptance level from the client </li></ul></ul><ul><ul><li>Client becomes familiar with the solution </li></ul></ul><ul><ul><li>Client involvement from the very start </li></ul></ul><ul><ul><li>Minimizes changes downstream </li></ul></ul><ul><ul><ul><li>Example 5.3, UC22 – Client Demographics storyboard excerpt (VA) </li></ul></ul></ul>5-47 Source: http://www.ganthead.com Example 5.3
    48. 48. Systems Design Considerations, cont. <ul><li>ISO/IEC 9126-1 Quality Attributes </li></ul><ul><ul><li>Functionality </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Efficiency </li></ul></ul><ul><ul><li>Maintainability </li></ul></ul><ul><ul><li>Portability </li></ul></ul><ul><ul><li>Usability </li></ul></ul><ul><ul><ul><li>Accessibility </li></ul></ul></ul>5-48
    49. 49. Topic Outline <ul><li>Systems design management concerns </li></ul><ul><li>Enterprise Architecture </li></ul><ul><li>Systems Architecture </li></ul><ul><li>Systems design considerations </li></ul><ul><li>Systems design approaches </li></ul><ul><li>Systems design deliverables </li></ul>5-49
    50. 50. <ul><ul><li>In 1970, less than 1 percent of the public could define what computer software meant </li></ul></ul><ul><ul><li>1980s and early 1990s </li></ul></ul><ul><ul><ul><li>Wide variety of object-oriented analysis (OOA) and design (OOD) methods </li></ul></ul></ul><ul><ul><ul><li>Source: Pressman, Roger, Software Engineering, sixth edition </li></ul></ul></ul>Brief History 5-50
    51. 51. Brief History, cont. <ul><li>1996 – Abundance of modeling languages was slowing down the adoption of object technology </li></ul><ul><ul><li>Under the leadership of the “three amigos” Grady Booch, James Rumbaugh, Ivar Jocobson </li></ul></ul><ul><ul><ul><li>International consortium called the UML Partners was organized </li></ul></ul></ul><ul><ul><ul><li>Combined the best object-oriented features </li></ul></ul></ul><ul><ul><ul><ul><li>“ Unified Method” </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Resulted in a “Unified Modeling Language (UML)” </li></ul></ul></ul></ul><ul><ul><ul><li>Robust notation for modeling and development of OO Systems </li></ul></ul></ul>5-51
    52. 52. Brief History, cont. <ul><ul><li>1997 - UML 1.1 was adopted in November </li></ul></ul><ul><ul><li>UML is now an international standard 1 </li></ul></ul><ul><ul><li>UML 2.0 adopted in October 2004 2 </li></ul></ul>5-52 Sources: 1 ISO/IEC 19501:2005 Information technology – Open Distributed Processing – Unified Modeling Language (UML) Version 1.4.2 2 http://en.wikipedia.org/wiki/Unified_Modeling_Language
    53. 53. UML Modeling <ul><li>Ability to model all elements of a computer-based system </li></ul>5-53
    54. 54. UML Modeling 5-54 Diagrams Structure Diagrams Behavior Diagrams Class Diagram Component Diagram Object Diagram Composite Diagram Deployment Diagram Package Diagram Activity Diagram Use Case Diagram State Diagram Interaction Diagrams Sequence Diagram Interaction Overview Diagram Communication Diagram Timing Diagram
    55. 55. UML Modeling, cont. <ul><li>Structure diagrams </li></ul><ul><ul><li>Emphasize what things must be in the system </li></ul></ul><ul><li>Behavior diagrams </li></ul><ul><ul><li>Emphasize what must happen in the system </li></ul></ul><ul><li>Interaction diagrams </li></ul><ul><ul><li>Emphasize the flow of control and data among the things in the system </li></ul></ul>5-55
    56. 56. UML Modeling, cont. <ul><li>Content </li></ul><ul><ul><li>Content to be provided by the application </li></ul></ul><ul><li>Functional </li></ul><ul><ul><li>What actions to apply to the content </li></ul></ul><ul><li>Interaction </li></ul><ul><ul><li>How the user interacts with the application </li></ul></ul><ul><li>Configuration </li></ul><ul><ul><li>Infrastructure where the application resides </li></ul></ul>5-56
    57. 57. System Design Approaches, cont. <ul><li>Traditional Waterfall </li></ul><ul><li>Incremental </li></ul><ul><li>Iterative </li></ul><ul><li>Rapid Application Development (RAD) </li></ul><ul><li>Spiral </li></ul><ul><li>Agile </li></ul><ul><li>Unified (UP) </li></ul><ul><li>Hybrid </li></ul>“ Our profession goes through methodologies like a 14-year-old goes through clothing.” Stepen Hawrysh and Jim Ruprecht 5-57
    58. 58. Traditional Waterfall Model 5-58
    59. 59. Waterfall, cont. <ul><li>Sequential flow </li></ul><ul><li>Approval at each phase completion </li></ul><ul><li>Product delivered at the end </li></ul><ul><li>Rework requires going back to the beginning </li></ul>5-59
    60. 60. Waterfall, cont. <ul><li>Advantages </li></ul><ul><ul><li>Deliverable at the end of each phase </li></ul></ul><ul><ul><li>Each phase can be estimated </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Projects rarely follow the sequential flow </li></ul></ul><ul><ul><li>Working version will not be available until the end of the project </li></ul></ul><ul><ul><li>Changes may require substantial rework </li></ul></ul>5-60
    61. 61. Terminology Cross Walk 5-61 Communication project initiation requirements Planning estimating scheduling tracking Modeling analysis design Develop code test Deploy delivery support feedback
    62. 62. Incremental <ul><li>Increment # 1 </li></ul><ul><li>Increment #2 </li></ul><ul><li>Increment # n </li></ul>5-62 Com Plan Model Develop Deploy Com Plan Model Develop Deploy Com- Communication Plan-Planning Model-Modeling Develop-Construction Deploy-Implement
    63. 63. Incremental, cont. <ul><li>Waterfall model applied in an iterative fashion </li></ul><ul><li>Combines elements of the waterfall model with approvals </li></ul><ul><li>First increment contains basic requirements </li></ul><ul><li>Second increment starts prior to first increment deployment </li></ul>5-63
    64. 64. Incremental, cont. <ul><li>Advantages </li></ul><ul><ul><li>Delivers an operational product </li></ul></ul><ul><ul><li>Next increment builds on the first </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Requires several increments to deliver a complete system </li></ul></ul>5-64
    65. 65. Iterative 5-65 Quick Plan Modeling Quick Design Develop Prototype Deployment Delivery Feedback Communication Start
    66. 66. Iterative, cont. <ul><li>General requirements </li></ul><ul><li>Quick design leads to a prototype </li></ul><ul><li>Customer sees a working version </li></ul><ul><li>It is meant to help define requirements </li></ul><ul><li>It is NOT meant to be a deployable solution </li></ul><ul><ul><li>Example 5.4, Iterative Flow Diagram (VA) </li></ul></ul>5-66 Example 5.4
    67. 67. Iterative, cont. <ul><li>Advantages </li></ul><ul><ul><li>Good way to refine objectives when requirements are fuzzy </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>User sees what appears to be a robust working system </li></ul></ul><ul><ul><li>Developers may be forced to implement a prototype </li></ul></ul>5-67
    68. 68. Rapid Application Development (RAD) <ul><li>Multiple Teams </li></ul>5-68 Com Plan Model Develop Model Develop Model Develop Deploy Com- Communication Plan-Planning Model-Modeling Develop-Construction Deploy-Implement
    69. 69. Rapid Application Development, cont. <ul><li>High speed adaptation of the waterfall model </li></ul><ul><li>Requirements are well understood </li></ul><ul><li>Project scope is limited </li></ul><ul><li>Project data </li></ul><ul><ul><li>Data already exists </li></ul></ul><ul><li>Project team </li></ul><ul><ul><li>Team is small (probably ten or less) </li></ul></ul>5-69
    70. 70. Rapid Application Development, cont. <ul><li>Project Technical Architecture </li></ul><ul><ul><li>Technical Architecture is defined and the key components are in place </li></ul></ul><ul><li>Project technical requirements </li></ul><ul><ul><li>Technical requirements are reasonable and within the current capabilities of the technology </li></ul></ul><ul><li>Project decisions </li></ul><ul><ul><li>Decisions can be made by a small number of people </li></ul></ul>5-70
    71. 71. Rapid Application Development, cont. <ul><li>Requires multiple RAD teams working in parallel </li></ul><ul><li>Fully functioning system within 60-90 days </li></ul>5-71
    72. 72. Rapid Application Development, cont. <ul><li>Advantages </li></ul><ul><ul><li>Can deliver an application in a short time </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Each module needs to be completed on time </li></ul></ul><ul><ul><li>Potential communications issues among teams </li></ul></ul><ul><ul><li>Teams need to be committed to rapid-fire activities </li></ul></ul>5-72
    73. 73. Spiral <ul><li>Series of Releases </li></ul>5-73 Com Plan Model Develop Deploy Com- Communication Plan-Planning Model-Modeling Develop-Construction Deploy-Implement Start
    74. 74. Spiral, cont. <ul><li>Couples iterative prototyping with controlled aspects of waterfall </li></ul><ul><li>Series of releases </li></ul><ul><li>Each release expands in complexity </li></ul><ul><li>Each release has a set of work products </li></ul><ul><li>Budget and time frames revisited with each release </li></ul>5-74
    75. 75. Spiral, cont. <ul><li>Advantages </li></ul><ul><ul><li>Rapid deployment of increasingly more complete versions of the software reduces risk </li></ul></ul><ul><ul><li>Set of anchor or control points </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>When will the entire system be completed? </li></ul></ul>5-75
    76. 76. Agile <ul><li>Built on the foundations of Iterative </li></ul><ul><li>Rapid incremental delivery of software </li></ul><ul><li>Informal methods </li></ul><ul><li>Minimal work products </li></ul><ul><li>Active and continuous communications between developers and customers </li></ul><ul><li>Processes user feedback rather than planning as the primary control mechanism </li></ul>5-76 Source: Wikipedia. Software Development Process.
    77. 77. Agile, cont. <ul><li>Must collaborate – face to face </li></ul><ul><li>Team must have decision-making authority </li></ul><ul><li>Must be adaptable to constant change </li></ul><ul><li>Most bang for the buck </li></ul><ul><ul><li>Won’t say exactly when the bang will be </li></ul></ul><ul><ul><li>Won’t say how big a buck will be required </li></ul></ul>5-77 Source: Wikipedia. Software Development Process.
    78. 78. Agile Process Models <ul><li>Agile process models include: </li></ul><ul><ul><li>Extreme Programming (XP) </li></ul></ul><ul><ul><ul><li>Object-oriented software </li></ul></ul></ul><ul><ul><ul><li>Driven by user stories (features and functions) </li></ul></ul></ul><ul><ul><ul><li>Pair Programming </li></ul></ul></ul><ul><ul><ul><li>Prototype </li></ul></ul></ul>5-78 <ul><li>Sources: </li></ul><ul><li>1 www.extremeprogramming.org </li></ul><ul><li>2 www.extremeprogramming.com </li></ul>
    79. 79. Agile Process Models, cont. <ul><ul><li>Adaptive Software Development 1 </li></ul></ul><ul><ul><ul><li>Project initiation sets release cycles </li></ul></ul></ul><ul><ul><ul><li>Joint Application Design (JAD) sessions </li></ul></ul></ul><ul><ul><ul><li>Focus groups for feedback </li></ul></ul></ul><ul><ul><ul><li>Adjustments for subsequent cycles </li></ul></ul></ul><ul><ul><li>Scrum 2 </li></ul></ul><ul><ul><ul><li>Small working groups </li></ul></ul></ul><ul><ul><ul><li>Frequent software increments (30 days) </li></ul></ul></ul><ul><ul><ul><li>Daily status meetings (15 minutes) </li></ul></ul></ul>5-79 <ul><li>Sources: </li></ul><ul><li>1 www.adaptivesd.com </li></ul><ul><li>2 www.controlchaos.com </li></ul>
    80. 80. Agile Process Models - Others <ul><li>Additional Agile process models references </li></ul><ul><ul><ul><li>Example 5.5, Additional Agile Models </li></ul></ul></ul>5-80 Example 5.5
    81. 81. Agile Process Models, cont. 5-81
    82. 82. Agile, cont. <ul><li>Advantages </li></ul><ul><ul><li>Adaptability to rapidly changing project and technical conditions </li></ul></ul><ul><ul><li>Incremental software releases </li></ul></ul><ul><ul><li>Allows for user feedback </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Minimum documentation </li></ul></ul><ul><ul><li>Constant changes - when does it get done? </li></ul></ul>5-82
    83. 83. Unified Process Terminology Cross Walk 5-83 Plan Model Develop Deploy Com Inception Elaboration Transition Release Com- Communication Plan-Planning Model-Modeling Develop-Construction Deploy-Implement Construction Start
    84. 84. Unified Process 5-84 <ul><li>Source: Rational Unified Process White paper. </li></ul><ul><li>http://medlem.spray.se/perlin27/rup.htm </li></ul>
    85. 85. Unified Process, cont. <ul><li>Inception </li></ul><ul><ul><li>User collaboration </li></ul></ul><ul><ul><li>Business requirements defined </li></ul></ul><ul><ul><li>Initial Use Case (10-20% complete) </li></ul></ul><ul><li>Elaboration </li></ul><ul><ul><li>Refined and expanded use case (80% complete) </li></ul></ul><ul><ul><li>Modeling </li></ul></ul>5-85
    86. 86. Unified Process, cont. <ul><li>Construction </li></ul><ul><ul><li>Code generation </li></ul></ul><ul><ul><li>System testing </li></ul></ul><ul><ul><li>User manuals </li></ul></ul><ul><li>Transition </li></ul><ul><ul><li>User testing </li></ul></ul><ul><ul><li>Operation manual </li></ul></ul><ul><ul><li>Data conversion </li></ul></ul><ul><ul><li>Training </li></ul></ul>5-86
    87. 87. Unified Process, cont. <ul><li>Best principles of Agile Software Development </li></ul><ul><li>Use case-driven </li></ul><ul><li>Iterative and Incremental </li></ul><ul><li>Unified Modeling Language (UML) </li></ul>5-87
    88. 88. Unified Process, cont. <ul><li>Advantages </li></ul><ul><ul><li>Creates and maintains models </li></ul></ul><ul><ul><li>Customer view of a system (use case) </li></ul></ul><ul><ul><li>Iterative and Incremental </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Heavy reliance on modeling (UML) </li></ul></ul><ul><ul><ul><li>Configuration management </li></ul></ul></ul><ul><ul><ul><li>Keeping models updated </li></ul></ul></ul>5-88
    89. 89. Hybrids <ul><li>State of Virginia </li></ul><ul><ul><li>Waterfall through Design </li></ul></ul><ul><ul><li>Iterative with a 22-day approval cycle </li></ul></ul><ul><ul><ul><li>Example 5.6, ChildWINS 22-day review (VA) </li></ul></ul></ul>5-89 Example 5.6
    90. 90. Topic Outline <ul><li>Systems design management concerns </li></ul><ul><li>Enterprise Architecture </li></ul><ul><li>Systems Architecture </li></ul><ul><li>Systems design considerations </li></ul><ul><li>Systems design approaches </li></ul><ul><li>Systems design deliverables </li></ul>5-90
    91. 91. Use Case <ul><li>Business use case </li></ul><ul><ul><li>Captures who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with internal system information </li></ul></ul><ul><ul><li>Describes the What </li></ul></ul><ul><li>A complete set of use cases </li></ul><ul><ul><li>Specifies all the different ways to use the system </li></ul></ul><ul><ul><li>Defines all behavior required of the system without specifying how the system does it </li></ul></ul>5-91
    92. 92. Use Case, cont. <ul><li>Business use case example </li></ul><ul><ul><li>Actor enters client ID to search for client record information </li></ul></ul><ul><ul><li>System accepts request and determines if client exists </li></ul></ul><ul><ul><ul><ul><li>Example 5.7, UC22 - Client Demographics Use Case (VA) </li></ul></ul></ul></ul>5-92 Example 5.7
    93. 93. Requirements Traceability <ul><li>Before executable code is created, the system requirements and design must be verified </li></ul><ul><li>Verification includes </li></ul><ul><ul><li>Walkthroughs and inspections of requirements documents, analysis documents, and design documents </li></ul></ul>5-93
    94. 94. Requirements Traceability, cont. <ul><li>Reduces the risk of requirements errors by </li></ul><ul><ul><li>Assisting with clarifying requirements </li></ul></ul><ul><ul><li>Determining impact of proposed system changes </li></ul></ul>5-94
    95. 95. Requirements Traceability, cont. <ul><li>A proven engineering technique that links system requirements </li></ul><ul><ul><li>Backward to their sources (e.g., stakeholders, federal and State laws and regulations) </li></ul></ul><ul><ul><li>Forward to the resulting system development work products </li></ul></ul><ul><ul><ul><li>Example 5.8, UC22 - Traceability Matrix excerpt (VA) </li></ul></ul></ul>5-95 Example 5.8
    96. 96. Requirements Traceability, cont. <ul><li>The most effective testing is driven by the business rules and requirements since you want to know whether the system does what it is intended to do for the business </li></ul><ul><li>Use cases are the logical place to start </li></ul><ul><ul><li>If you do not follow a use case format for requirements, start with individual, specific requirements </li></ul></ul>5-96
    97. 97. Systems Design Deliverables <ul><li>Every business use case and system use case should have corresponding test cases and scripts that test the system’s functionality and verify that the requirements are met </li></ul>5-97
    98. 98. Systems Design Deliverables, cont. <ul><li>Architecture </li></ul><ul><ul><li>Overall system structure/framework </li></ul></ul><ul><ul><ul><li>How to handle user interaction </li></ul></ul></ul><ul><ul><ul><li>How to handle internal processing tasks </li></ul></ul></ul><ul><ul><li>Data flow model/diagrams </li></ul></ul><ul><ul><li>Entity-Relationship Diagram </li></ul></ul><ul><ul><ul><li>Data objects and their relationships </li></ul></ul></ul><ul><ul><li>Logical Data Model </li></ul></ul><ul><ul><li>Physical Data Model </li></ul></ul><ul><ul><li>Data Conversion Plan </li></ul></ul>5-98
    99. 99. Systems Design Deliverables, cont. <ul><li>Component-level </li></ul><ul><ul><li>Detailed processing logic </li></ul></ul><ul><ul><li>Component diagrams </li></ul></ul><ul><ul><ul><li>Detailed set of specifications for each module </li></ul></ul></ul><ul><ul><ul><ul><li>Example 5.9, CAPS Design Document (TX) </li></ul></ul></ul></ul><ul><ul><li>Sequence Diagrams </li></ul></ul><ul><ul><ul><li>How events cause transitions from object to object </li></ul></ul></ul>5-99 Example 5.9
    100. 100. Systems Design Deliverables, cont. <ul><ul><li>Activity Diagrams </li></ul></ul><ul><ul><ul><li>Flow of interaction </li></ul></ul></ul><ul><ul><ul><ul><li>Example 5.7, UC22-Client Demographics Use Case (VA) - Page 7 of 8 </li></ul></ul></ul></ul><ul><ul><li>Design classes </li></ul></ul><ul><ul><ul><li>Example 5.10, Domain Model (VA) </li></ul></ul></ul><ul><ul><ul><li>Example 5.11, Design Class Document (VA) </li></ul></ul></ul>5-100 Examples 5.7, 5.10 & 5.11
    101. 101. Systems Design Deliverables, cont. <ul><li>Interface </li></ul><ul><ul><li>Technical Interface Design </li></ul></ul><ul><ul><ul><li>Example 5.12, DFPS Interfaces (TX) </li></ul></ul></ul><ul><ul><ul><li>Example 5.13, IMPACT Central Registry (TX) </li></ul></ul></ul><ul><ul><ul><li>Example 5.14, IMPACT Interfaces (TX) </li></ul></ul></ul><ul><ul><ul><li>Example 5.15, IMPACT DARS ECI Interface (TX) </li></ul></ul></ul><ul><ul><ul><li>Screen designs/user interface model </li></ul></ul></ul><ul><ul><li>Look and feel </li></ul></ul><ul><ul><li>How the end user navigates </li></ul></ul><ul><ul><li>Color schemes, text size, font, placement </li></ul></ul><ul><ul><li>Report layouts </li></ul></ul>5-101 Examples 5.12, 5.13, 5.14, 5.15
    102. 102. Systems Design Deliverables, cont. <ul><li>Other considerations </li></ul><ul><ul><li>Security Plan/impacts </li></ul></ul><ul><ul><li>Hardware capacity planning </li></ul></ul><ul><ul><li>Network impact planning </li></ul></ul><ul><ul><li>Bandwidth </li></ul></ul>5-102
    103. 103. Exercise <ul><li>Using the Design Approaches from the previous slides, or from your own experience: </li></ul><ul><ul><li>Describe your State/county’s approach (or approaches) to design. </li></ul></ul><ul><ul><li>What do you like or dislike about each approach? Why? </li></ul></ul><ul><ul><li>Contribute your results to a full class discussion. </li></ul></ul><ul><li>Time: 20 minutes </li></ul>5-103
    104. 104. Exercise Results <ul><li> Class List: States’ Approaches to Systems Design </li></ul><ul><li>1. </li></ul><ul><li>2. </li></ul><ul><li>3. </li></ul><ul><li>4. </li></ul><ul><li>5. </li></ul>5-104
    105. 105. Topic Summary <ul><li>Project failures are a result of unclear requirements and/or excessive changes </li></ul><ul><li>Common threads throughout a project are risk management, change control, managing user expectations and communications </li></ul>5-105
    106. 106. Topic Summary, cont. <ul><li>Regardless of the type of project, IT or otherwise, relationships with the project team and stakeholders can make or break the possibilities for success </li></ul><ul><li>Design starts with Enterprise Architecture - the relationship between the business, technology and information </li></ul>5-106
    107. 107. Topic Summary, cont. <ul><li>Systems Architecture illustrates potential tradeoffs in systems design </li></ul><ul><li>In designing a system, collaborate, collaborate, collaborate </li></ul><ul><li>There is no right or wrong design approach. Pick one that works for you. </li></ul>5-107