240 likes | 407 Views
Chapter 1, Introduction to Software Engineering. Software Engineering. Software systems are complex Impossible to understand by a single person Many projects are never finished: "vaporware" The problem is arbitrary complexity 1968 Definition:
E N D
Software Engineering • Software systems are complex • Impossible to understand by a single person • Many projects are never finished: "vaporware" • The problem is arbitrary complexity • 1968 Definition: • Software Engineering means the construction of quality software with a limited budget and a given deadline • Our definition: • Software Engineering means the construction of quality software with a limited budget and a given deadline in the context of constant change • Emphasis is on both, on software and on engineering
Course format • A Single Semester Course • Lectures: Theoretical foundations and background • Project: Learn how to apply them in practice • Lectures and Project work are interleaved • Everybody will participate in a software project
Objectives of this course • Acquire technical knowledge • Understand difference between program and software product • Be able to reconstruct the analysis and design of an existing software system • Be able to design and implement a subsystem that will be part of a larger system • Acquire managerial knowledge • produce a high quality software system within budget & time • while dealing with complexity and change
Emphasis is on team work • Participate in collaborative design • Work as a member of a project team, assuming various roles • Create and follow a project and test plan • Create the full range of documents associated with a software product • Complete a project on time
How can we accomplish this? • Course Projects • Internet Ordering System • Internet Sales Tracking System • You will organize into groups of 3 • Each group will be assigned a project • Details will be revealed once the groups are formed • Course project will be done in 3 stages • Requirements elicitation • Analysis and design • Implementation
Assumptions and Requirements for this Class • Assumption: • You are proficient in a programming language (Java preferred), but have no experience in analysis or design of a system • You have access to a Web Browser • Course Homepage: http://www.cs.fiu.edu/~ege/cen4010/ • Requirements: • You have taken required courses (Programming III, Data Structures) • or • You have practical experience with maintaining or developing a large software system
Textbooks • Textbook • Bernd Bruegge and Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing Systems, Prentice Hall, 2000. • Optional Readings • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns, Addison-Wesley, 1996, ISBN 0-201-63361-2 • Ivar Jacobson, M. Christerson, P. Jonsson, G. Övergaard, "Object-Oriented Software Engineering" , Addison Wesley, 1992 • Grady Booch, "Object-Oriented Design with Applications", Benjamin Cummings, 1991. • James Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Object-Oriented Modeling and Design, Prentice Hall, 1991
Ground Rules • Attendance: • Attendance and class participation is required • Every project team member is responsible for the whole project • Grading: • Midterm exam 30% • Final exam 30% • Group project 40% • Requirements document 30% • Design document 40% • System implementation 30%
Project • Each team must: • Submit a bi-weekly activity log • Submit a Requirement Analysis Document • Submit an Object Design Document • Demonstrate the entire running program • Each of the above also require a 15 minutes in class presentation • Every team member is responsible for the entire project
What is Software Engineering • Software Engineering is the construction of quality software with a limited budget and a given deadline • How about change? • Software Engineering is the construction of quality software with a limited budget and a given deadline in the context of constant change • Emphasis is on both, on software and on engineering
Why Software Engineering • Software Systems are complex: • Impossible to understand by a single person • Many projects are never finished • The problem being solved is arbitrarily complex • Software Systems are subject to constant change
What are the activities? • Modeling • An abstract representation of a system that allows the software engineer to answer questions about the system • Models allow visualizing and understanding systems that are • too large • too complex • too expensive for direct experimentation • or do not even exist in the real world • Problem Solving • Find a solution with incomplete knowledge and limited resources • Formulate the problem • Analyze the problem • Search for solutions • Select an appropriate solution • Specify the solution
What are the activities? • Knowledge Acquisition • software Engineer must acquire problem domain knowledge required to develop the target system • is nonlinear • Rationale Management • Justification of decisions • issues that were addressed • alternatives that were considered • decisions that were made to resolve the issues • the criteria that were used to guide decisions • the underlying debates
Concepts • A project’s purpose is to develop a software system • A project is composed of a number of activities • An activity is composed of a number of tasks • A task consumes resources and produces a work product • work product: • a system • a Model • a document • resource: • time • equipment • personnel
Project Activity * WorkProduct Task Resources is produced by consumes * * * System Participant Model Time Document Equipment Concepts -- UML
Development Activities • Requirement Elicitation • Analysis • System Design • Object Design • Implementation
Requirement Elicitation • Define the purpose of the system • Describe the system in terms of actors and use cases • Actors: • External entities that interact with the system • Use Cases: • Sequences of events that describe all possible actions between actors and the system
Analysis • Produce a model of the system that is: • Correct • Complete • Consistent • Unambiguous • Realistic • Verifiable • Transform use cases into object model
System Design • Define the design goals • Decompose the system into smaller subsystems • Select strategies for building the system
Object Design • Precisely describe object and system interfaces • Select off-the shelf components • Restructure the object model to attain design goals: • Extensibility • Understandability • Performance optimization • Result: • Detailed object model
Implementation • Translate the object model into source code • Implement the attributes and methods of each object • Integrate all the objects
Managerial Aspects • Communication • Rationale Management • Testing • Discover as many faults as possible and repair them before the delivery • Software Configuration Management • Monitor and control changes • Software Project Management • Budgeting • Hiring • Tracking progress, etc. • Software life cycle modeling
Summary • Find the class website • Read Chapter 1 • Form your teams