1 / 18

Software SYSTEMS DEVELOPMENT

Software SYSTEMS DEVELOPMENT. 4: System Design. Simplified view on software product development process. Why do we need the design phase?. Make sure requirements are feasible To plan and estimate the work to be done Communications (development teams/support/customer etc.)

rachelle
Download Presentation

Software SYSTEMS DEVELOPMENT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software SYSTEMS DEVELOPMENT 4: System Design

  2. Simplified view on software product development process

  3. Why do we need the design phase? • Make sure requirements are feasible • To plan and estimate the work to be done • Communications (development teams/support/customer etc.) • Prepare for change

  4. Software Architecture • “Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled”. • “Architecture is everything that is expensive to change later” • Communications=>Documentation

  5. Documenting Architecture: Views • Decomposition of the system into elements • Relationships among elements and attributes of these elements • Run-time vs. Static decomposition?

  6. Architecture: Views • Multiple views to capture different aspect of the system: • Functional: elements and connectors • Information: data entities and relationships • Development: layers and modules • Concurrency: processes and threads • Deployment: hardware, network

  7. A Functional View: Layered Style

  8. An Information: View Entity Relationship Diagram

  9. A Development View: Class Diagram

  10. Architecture Evaluation • Make sure there is a flow in functional view for each software requirements (SRS) • Make sure there is required set of classes/modules in development view • Make sure all required data is present and maintained correctly

  11. Some important points • Detalization -Abstraction trade-off • Development view has enough information for reliable estimation of work to be done • Prepare to change • Run “what-if” analysis on the architecture. See scope and place of changes • Knowledge reuse • Architecture styles(client-server, multitier) and patterns

  12. Software Quality • Run-Time Quality • Non-Runtime System Qualities • Business Qualities • Architecture Qualities • Domain Specific Qualities

  13. Runtime System Qualities • Functionality Definition: the ability of the system to do the work for which it was intended. • Performance Definition: the response time, utilization, and throughput behavior of the system. Not to be confused with human performance or system delivery time.  • Security Definition: a measure of system’s ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users. • Availability Definition: the measure of time that the system is up and running correctly; the length of time between failures and the length of time needed to resume operation after a failure. • Usability Definition: the ease of use and of training the end users of the system. Sub qualities: learnability, efficiency, affect, helpfulness, control. • Interoperability Definition: the ability of two or more systems to cooperate at runtime

  14. Non-runtime • Modifiability Definition: the ease with which a software system can accommodate changes to its software • Portability Definition: the ability of a system to run under different computing environments. The environment types can be either hardware or software, but is usually a combination of the two. • Reusability Definition: the degree to which existing applications can be reused in new applications. • Integrability Definition: the ability to make the separately developed components of the system work correctly together. • Testability Definition: the ease with which software can be made to demonstrate its faults

  15. Business Qualities • Cost and Schedule Definition: the cost of the system with respect to time to market, expected project lifetime, and utilization of legacy and COTS systems. • Marketability Definition: the use of the system with respect to market competition. • Appropriateness for OrganizationDefinition: availability of the human input, allocation of expertise, and alignment of team and software structure. Business process re-engineering

  16. Architecture Qualities • Conceptual Integrity Definition: the integrity of the overall structure that is composed from a number of small architectural structures. • Correctness Definition: accountability for satisfying all requirements of the system. 

  17. Our focus • Run-time: Functionality • Non-runtime: Modifiability • Business: Cost and Schedule • Architecture: Correctness

  18. SDD Document: 3 pages/diagrams • Functional (Logical) Architecture diagram • ER Diagram • Class diagram including major classes (top 10 or less) with top 5 methods/attributes per class

More Related