Focus on design principles and on a process for doing design = To produce a precise, complete, high- quality foundation for product implementation.

Slides:



Advertisements
Similar presentations
Object Oriented Analysis And Design-IT0207 iiI Semester
Advertisements

What is Software Design?. Systems Development Life- Cycle Planning Analysis Design Implementation Design.
The software process A software process is a set of activities and associated results which lead to the production of a software product. This may involve.
Chapter 2 – Software Processes
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Chapter 10 Schedule Your Schedule. Copyright 2004 by Pearson Education, Inc. Identifying And Scheduling Tasks The schedule from the Software Development.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #7 Software Engineering.
6/19/2007SE _06_19_Overview_Inspections.ppt1 Team Software Project (TSP) June 19, 2007 High Level Designs, Code Inspections & Measurement.
6/19/2007SE _6_19_TSPImp_SVT_Lecture.ppt1 Implementation Phase Inputs: Development strategy & plan Completed, inspected & baselined SRS & SDS.
06/12/2007SE _6_12_Design.ppt1 Design Phase Outputs: Completed & Inspected SDS & Integration Test Plan Completed & Inspected System Test Plan.
SE 555 Software Requirements & Specification Requirements Validation.
SE 555 – Software Requirements & Specifications Introduction
8/7/2007SE _8_07_Misc_PostMortem.ppt1 Additional Topics & Team Project Post-Mortem.
Introduction to Software Testing
Personal software process Mohammed ahmed ali. What is psp The personal software process (psp) is a structured set of process descriptions, measurements.
1 Software Testing Techniques CIS 375 Bruce R. Maxim UM-Dearborn.
SystematicSystematic process that translates quality policy into measurable objectives and requirements, and lays down a sequence of steps for realizing.
Acquiring Information Systems and Applications
Effective Methods for Software and Systems Integration
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
Use Cases Why use ‘em? How do they work? UC diagrams Using them later in the software development cycle.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #14 Software Engineering.
CHAPTER 5 Infrastructure Components PART I. 2 ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser 2 Learning Objectives: To discuss: The need for SQA procedures.
Extreme Programming Software Development Written by Sanjay Kumar.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
INFO 637Lecture #81 Software Engineering Process II Integration and System Testing INFO 637 Glenn Booker.
CLEANROOM SOFTWARE ENGINEERING.
INFO 637Lecture #61 Software Engineering Process II Designing with Teams INFO 637 Glenn Booker.
S oftware Q uality A ssurance Part One Reviews and Inspections.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
INFO 637Lecture #41 Software Engineering Process II Development Plan INFO 637 Glenn Booker.
Software Inspection A basic tool for defect removal A basic tool for defect removal Urgent need for QA and removal can be supported by inspection Urgent.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
1 Software testing. 2 Testing Objectives Testing is a process of executing a program with the intent of finding an error. A good test case is in that.
Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITHClass of 39 CS3600: Software Engineering: Standards in Process Modeling CMM and PSP.
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem Darwish.
INFO 637Lecture #21 Software Engineering Process II TSP Roles and Overview INFO 637 Glenn Booker.
Disciplined Software Engineering Lecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
Lecture 7: Requirements Engineering
INFO 637Lecture #101 Software Engineering Process II Review INFO 637 Glenn Booker.
Software Engineering Prof. Dr. Bertrand Meyer March–June 2007 Chair of Software Engineering Lecture 2: The Personal Software Process.
Team Software Process (TSPi) CS4320 Fall TSP Strategy Provide a simple process framework based on the PSP. Use modest, well-defined problems. Develop.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 7 1 Design and Code Reviews - Overview What are design and code.
Chapter 4 프로세스 모델 Process Models
Reviews and Inspections. Types of Evaluations Formal Design Reviews conducted by senior personnel or outside experts uncover potential problems Inspections.
PRJ566 Project Planning & Management Software Architecture.
Sponsored by the U.S. Department of Defense © 2002 by Carnegie Mellon University July 2002 PSP-TSPi Faculty Workshop Pittsburgh, PA Lecture.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Chapter 8. The Process Phases 1. Launching teams 2. The development strategy 3. Team planning 4. The requirements process 5. Designing with teams 6. Implementation.
THE POSTMORTEM Chapter 10 Introduction to Team Software Process.
INFO 637Lecture #71 Software Engineering Process II Product Implementation INFO 637 Glenn Booker.
PRODUCT IMPLEMENTATION Chapter 8 Tawatchai Iempairote September 23, 2041.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
Integration and system test
 Software Testing Software Testing  Characteristics of Testable Software Characteristics of Testable Software  A Testing Life Cycle A Testing Life.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
CS 350, slide set 10 M. Overstreet Old Dominion University Spring 2005.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
TMP3413 Software Engineering Lab Lab 01: TSPi Tool Support.
1 Multimedia Development Team. 2 To discuss phases of MM production team members Multimedia I.
Enterprise Architectures Course Code : CPIS-352 King Abdul Aziz University, Jeddah Saudi Arabia.
 System Requirement Specification and System Planning.
Software Quality Control and Quality Assurance: Introduction
IEEE Std 1074: Standard for Software Lifecycle
Presentation transcript:

Focus on design principles and on a process for doing design = To produce a precise, complete, high- quality foundation for product implementation

 Design principle  Designing in teams  Design standards  Designing for reuse  Designing for usability  Designing for testability  Design reviews & inspections

 Creative process; produce complete and precise specification of how to build a product  Complete design defines the principal parts, describe how they interact, and how they put together to produce the finished result.

 After the requirements have been defined, the entire software process concerns various levels of design;  The high-level design must produce a SDS ( Software Design Specification) , which includes the complete functional specifications of each component, its interface and its state behavior

PRODUCT Component Part2Component Part1Component Part n Team Member 1Team Member nTeam Member 2 Designed & Implemented Designed & Implemented Designed & Implemented SDS the complete functional specifications of each component, its interface and its state behavior.

 The detailed design defines the logical structure, all the loop initialization and stepping conditions, the detailed state structure, and the state transitions for every pr ogram.  If the High-level design is vague or imprecise, the engineers have to fill the gap component incompatibilities, detected in integration & system test..

 High-level design differs from detailed design only in scope and detail.  In TSPi, the high-level design process is described in the design phase. The detailed-design process is described in the implementation phase.

 Using entire team  Design Studies  Using all the team’s talents Who should design each part? In what order? How do the parts fit together?

 Common problem in designing large software system = the need to define the overall system structure. If not, difficult to divide the work.  To have the entire team work together on the overall structure design. => An attractive alternative

 The entire team brainstorms the initial design ideas.  Once the team has picked a general approach, only one or two engineers are usually needed to document the highest level design, specify the interfaces, allocate system functions among the components, and define the overall program structure and logic.  And identify other team tasks could do:- design studies, standards development, and reuse.

 Design Studies › While the system designers are producing the external component specifications, other could think about alternative ways to design the components => to build the prototype, and user interface.

 Using All the Team’s Talents › Powerful range of skills and knowledge › To get all the members to fully contribute  Ask if anyone has further ideas or relevant knowledge on the topics Speak up

 Some important types of design standards; › Naming conventions › Interface formats › System and error messages › Defect standards* › LOC counting › Design representation standards

 Design Representation Standards  To know having the complete design, need a specification for what a complete design contains  Need to precisely document every design by using the 4 PSP design templates › The operational scenario template › The functional specification template › The state specification template › The logic specification template COMPLETE & PRECISE

 Reuse is a potentially powerful way to increase team productivity.  By establishing a reuse program, you can often save engineering time in development cycles.  Teams generally achieve higher reuse level when s/o produces an initial reuse standard and specifies a starter set of reusable parts:- › Reuse interface standards › Reuse documentation standards › Reuse part quality › Application support.

Reuse Interface Standards  One key issue of reuse: make parts convenient to use. To define reusable functions that are self-contained & cleanly isolated  Ex: the call-return interfaces

Reuse Documentation Standards Reuse Part Quality High Quality  Because give up if its first defect found.  To achieve the high part quality Use a fully defined process & conduct personal reviews & peer inspections of both the design and the code Application Support

 One way to make products usable is to produce scenarios for every key user function (reflect the kind of system you believe the users will want.)  *** Good idea to prototype and demonstrate all user interfaces.

 Black-box testing  White-box testing

 For improving the quality of your design.  A well-document design design analysis (check each design element => interfaces, state behavior.

 A development strategy  A development plan  A completed and inspected SRS Can’t do a competent design job unless you have a high-quality SRS that has been Inspected. The team must have agree on how to represent the completed design.

The development manager leads the team through…  Decide on the overall product structure.  Name the product components.  Allocate product function to components  Produce the component external specifications  Allocate use-cases function to these components.  Identifying the design tasks to be completed and documented.

 The quality/process manager leads the team to produce the design standards and name glossary.

 [Overall design specified and the components named] => produce the design specifications  The development manager lead  Lay out the design of the SDS document + identify the work needed to produce & dividing this work into sections. Allocate & get the commitment

 Each team member  Produces and reviews his or her portions of the SDS document  Provides these to the development manager  The development manager produces a composite SDS draft.

 to produce the integration test plan while you are producing the design specifications check & verify all interfaces  Inspect the integration test plan when inspect the SDS.

 The quality/process manager leads all the team through inspecting the SDS draft and integration test plan. to find maximum no. of design defects. to ensure all team understand the design. The inspection is documented in form INS and defects are recorded in LOGD.

 Team member fix the identified errors in SDS/ integration test plan  The development manager obtains the updated SDS and integration test plan sections and c ombine them into a final SDS and integration test plan  Distributes.

 The support manager baselines an official SDS copy, which the team can now change only by using the change control procedure (form CCR).

The final design products are …  The completed, inspected and corrected SDS, + all design material  The completed, inspected and corrected integration test plan  The design standard and name glossary  The completed inspection forms (INS)  Updated SUMP and SUMQ forms  Update time, size, defect  Updated the project notebook (copy all design materials)

 To ensure that engineers produce high- quality design.

Produce overall design Divide into principal components Design B Design ADesign C The development manager SDS

 Precise, complete, high-quality  How the product part interact  How assembled to the finished system

 Deciding on the overall product structure  Allocating product functions to components  Producing the component external specifications  Deciding which components & functions to develop in each development cycle. + REUSE and STANDARDS