WELCOME TO SENG 411 KEYWORD TEAM WORK http

WELCOME TO SENG 411! KEYWORD: TEAM WORK! http: //sern. ucalgary. ca/courses/cpsc/451/F 00/cpsc 451. html#RTFTo C 3

MOTTO • IS NOT THE LOAD THAT BRINGS YOU DOWN – IS THE WAY YOU CARRY IT ! • LOOK AT THE BRIGHT SIDE! • CELEBRATE YOUR TEAM PARTNERS (and encourage!) • RESPECT THE DIFFERENCES • EXTEND YOUR BOUNDAIRES!

PURPOSE • To provide an overview of techniques and methodologies for applied software engineering. • ? WHAT IS SOFTWARE ENGINEERING • ? WHY DO WE NEED IT

SOFTWARE ENGINEERING • The Science (proof via scientific method) and Art (creativity) of Designing complex software systems • Design - disciplined approach to invent a solution for some problem the path from requirements to implementation

DISCIPLINE • NEEDED TO DEAL WITH COMPLEXITY • TOOL FOR MANAGING CHAOS (to order and clarify) • RULES • Design - Creates a simple and clear internal structure (architecture) by balancing competing requirements

EXAMPLE • Date/ Artifact/ Marks (% of project) • 18 Sept /C 1: Informal Specification of Requirements/ 2% • 25 Sept /S 1: Functional Spec. and Mgmt Plan /10%

WHY? • THE ‘HORROR’ STORIES • ‘A hospital minicomputer, monitoring a patient recovering from surgery, fails to alert hospital staff that the patient is having a stroke. The patient dies. ’ -- Washington Post

WHAT DO WE NEED? • Problems stem from an unrealistic view of what it takes to construct the software to perform these tasks. • THIS CALLS FOR: • better understand the development process; • learn how to estimate trade off time, manpower, dollars; • estimate and measure the quality, reliability, and cost of the end product.

Software Life Cycle • Waterfall Model

PROBLEMS • The rigid sequential flow of the model is rarely encountered in real life. Iteration can occur causing the sequence of steps to become muddled. • It is often difficult for the customer to provide a detailed specification of what is required early in the process. Yet this model requires a definite specification as a necessary building block for subsequent steps. • Much time can pass before any operational elements of the system are available for customer evaluation. If a major error in implementation is made, it may not be uncovered until much later.

PROTOTYPING

APPLICABILITY • In object oriented programming a library of reusable objects (data structures and associated procedures) the software engineer can rapidly create prototypes and production programs. • Prototyping is applicable only to a limited class of problems. In general, a prototype is valuable when heavy humanmachine interaction occurs, when complex output is to be produced or when new or untested algorithms are to be applied. It is far less beneficial for large, batch-oriented processing or embedded process control applications

BENEFITS • • • a working model is provided to the customer/user early in the process, enabling early assessment and bolstering confidence, the developer gains experience and insight by building the model, thereby resulting in a more solid implementation of "the real thing" the prototype serves to clarify otherwise vague requirements, reducing ambiguity and improving communication between developer and user.

DRAWBACKS • • The user sees what appears to be a fully working system (in actuality, it is a partially working model) and believes that the prototype (a model) can be easily transformed into a production system. This is rarely the case. Yet many users have pressured developers into releasing prototypes for production use that have been unreliable, and worse, virtually unmaintainable. The developer often makes technical compromises to build a "quick and dirty" model. Sometimes these compromises are propagated into the production system, resulting in implementation and maintenance problems.

Project Phases for the Development of Large Systems • • • • Initial conception Requirements analysis Specification Initial design Verification and test of design Redesign Prototype manufacturing Assembly and system-integration tests Acceptance tests (validation of design) Production (if several systems are required) Field (operational) trial and debugging Field maintenance Design and installation of added features System discard (death of system) or complete system redesign.

Boehm’s Estimates • • 40% of effort on analysis and design 20% on coding and auditing (handchecking) 40% on testing and correcting bugs. (Documentation was not included, estimated at extra 10%. )

Cost of Changes • • • Testing becomes more complex and costly; Documentation of changes becomes more widespread and costly; Communication of problems and changes involves many people; Repeating of previous tests (regression testing) becomes costly; Once operation is begun, the development team is disbanded and reassigned.