CMSC 345 Fall 2000 Software Design and Development

Instructor Instructor: Dennis L. Frey Office: ECS Office Hours: TuTh 10:00 – 12:00

TA TA: Mahesh Gandhe Office: Office Hours: MW TBD

Course Materials Course homepage /345/fall00 Course Description Objective Textbooks Grading Class Schedule

What is Software Engineering? SW Engineering focuses on the computer as a problem-solving tool instead of investigating HW design or proving theorems about algorithms Any hacker can write code. SW Engineering is about designing and developing high-quality software

Why Software Engineering Writing a program is easy Developing a software product is hard High-quality software products are robust, efficient and effective High-quality software products are easy to understand, modify and compose with other high-quality software products Software engineers are skilled professionals who follow “best practices”

Management Myth Myth: If we get behind schedule, we can add more programmers to catch up. Reality: The mythical man-month - “… adding people to a late software project makes it later”. Why? People can be added, but in a planned and well-coordinated manner.

Customer Myth Myth: A general statement of objectives is sufficient, we will fill in the details later. Reality: Poor up-front definition is the major cause of failed software efforts.

Customer Myth Myth: Project requirements continually change, but change can easily be accommodated because software is flexible. Reality: It is true that software requirements do change, but the impact of change varies with the time the change is introduced.

Cost of Change DevelopmentDefinitionMaintenance to 6 60 to 100

Practitioner Myth Myth: Once we write the program and get it to work, our job is done. Reality: Industry data shows that 50%- 70% of all effort expended on a program is expended after it is delivered to the customer.

Practitioner Myth Myth: The only deliverable for a successful project is the working program. Reality: A working program is only one part of the software configuration. Documentation forms the foundation for a successful development and provides guidance for the software maintenance task.

Who does SW Engineering? Stakeholders working together as a team. Usually 3 categories Customer User Developer

CUSTOMER Sponsors system development USER Uses system DEVELOPER Builds system Contractual obligation $$$, needs Software system Needs

A Systems Approach Projects do not exist in a vacuum Must provide a context System Boundaries Elements of a system Activities Objects (Entities) Relationships Definition of the boundary

Building the system Determine the requirements Create a system design Design individual programs Test the programs in pieces Test the programs together Deliver the system

The Development Team Requirements analyst Designers Programmers Testers Customers Trainers Maintenance team

MAINTENANCE SYSTEM DESIGN REQUIREMENTS ANALYSIS AND DEFINITION PROGRAM DESIGN PROGRAM IMPLEMENTATION UNIT TESTING INTEGRATION TESTING SYSTEM TESTING SYSTEM DELIVERY SOFTWARE DEVELOPMENT STEPS DEVELOPER ROLES ANALYST DESIGNER PROGRAMMER TESTER TRAINER

The Product Elementary School mathematics testing system User interface Database Multiple user types Reporting

New Skills GUI on Unix Tcl/Tk curses RCS for version control Multi-user system design client/server