IS F341 : Software Engineering

1. IS F341 : Software Engineering Software Engineering

2. Software Myths - Management • "We already have a book that is full of standards and procedures for building software. Won't that provide my people with everything they need to know?" • Not used, not up to date, not complete, not focused on quality, time, and money • "If we get behind, we can add more programmers and catch up" • Adding people to a late software project makes it later • Training time, increased communication lines • "If I decide to outsource the software project to a third party, I can just relax and let that firm build it" • Software projects need to be controlled and managed

3. Software Myths - Customer • "A general statement of objectives is sufficient to begin writing programs – we can fill in the details later" • Ambiguous statement of objectives spells disaster • "Project requirements continually change, but change can be easily accommodated because software is flexible" • Impact of change depends on where and when it occurs in the software life cycle (requirements analysis, design, code, test)

4. Software Myths - Practitioner • "Once we write the program and get it to work, our job is done" • 60% to 80% of all effort expended on software occurs after it is delivered • "Until I get the program running, I have no way of assessing its quality • Formal technical reviews of requirements analysis documents, design documents, and source code (more effective than actual testing) • "The only deliverable work product for a successful project is the working program" • Software, documentation, test drivers, test results • "Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down" • Creates quality, not documents; quality reduces rework and provides software on time and within the budget 

5. Goals of the Course • Learn to design & build real systems • learn factual SE information • apply SE “book” knowledge to real problem • develop interesting software systems • learn how to work together on a team project • practice communicating your results • key to your future success Software Engineering

6. Outline • Software Development Process • Software Life Cycle Models • Software Process Assessment and Improvement - CMM Software Engineering

7. A Layered Technology Software Engineering tools methods process model a “quality” focus • Any engineering approach must rest on organizational commitment to qualitywhich fosters a continuous process improvement culture. • Processlayer as the foundation defines a framework with activities for effective delivery of software engineering technology. Establish the context where products (model, data, report, and forms) are produced, milestone are established, quality is ensured and change is managed. • Methodprovides technical how-to’s for building software. It encompasses many tasks including communication, requirement analysis, design modeling, program construction, testing and support. • Toolsprovide automated or semi-automated support for the process and methods.

8. What do we want in a system? • Reliability • Efficiency • Maintainable/ Adaptable • Accessible / Usable (nice interface, design, comfortable) • Cost Effectiveness • Safety • Robustness • Recoverability • Portability • Understandability Software Engineering

9. Solutions? • Think - what is wanted - what is feasible - what is critical • Plan • Think again • Build • Check / Test • Make changes • Release • Fix => A process. Software Engineering

10. Input Output Output Input Output Input Input Process Step Step 1 Step 2 Sequential or linear process Software Engineering

11. Output Input Input Step 1 Step 3 Output Input Step 2 Output Input Concurrent Process Parallel or concurrent process Software Engineering

12. Output Input Input Step 1 Step 3 Output Input Step 2 Output Input Iterative Process Iterative process Software Engineering

13. Features of a process • One or more steps. • Each step is well defined. • Input and output of each step is well defined and observable. • Start and end of a step can be identified. Software Engineering

14. Process Specification • Process is generally a set of phases • Each phase performs a well defined task and generally produces an output • Intermediate outputs – work products • At top level, typically few phases in a process • How to perform a particular phase – methodologies have been proposed Sofware Process

15. ETVX Specification • ETVX approach to specify a step • Entry criteria: what conditions must be satisfied for initiating this phase • Task: what is to be done in this phase • Verification: the checks done on the outputs of this phase • eXit criteria: when can this phase be considered done successfully • A phase also produces information for management Sofware Process

16. ETVX approach Sofware Process

17. Software Development Process • Steps correspond to one or more tasks related to software development. • Tasks: • Integration • Requirements gathering • Test • Requirements analysis • Delivery • Design • Maintenance • Coding • Training • Software life cycle: Software Life Cycle consists of all phases from its inception until its retirement. These are (for Unified Process): Inception, elaboration, construction, transition. Software Engineering

18. The software process • Software process: organizing a structured set of activities to develop software systems. • Many different software processes but all involve the following activities: • Specification – defining what the system should do; • Design and implementation – defining the organization of the system and implementing the system; • Validation – checking that it does what the customer wants; • Evolution – changing the system in response to changing customer needs. Software Engineering

19. Software Process Model descriptions • A software process model is an abstract representation of a process. It presents a description of a process. • When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities. • Process descriptions may also include: • Products, which are the outcomes of a process activity; • Roles, which reflect the responsibilities of the people involved in the process; • Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced. • Notation: activities, products Software Engineering

20. Software Life Cycle Model • Definition • Describes an abstract collection of software processes that share common characteristics such as timing between phases, entry and exit criteria for phases. • The models specifies • the various phases of the process • e.g., requirements, specification, design… • the order in which they are carried out Software Engineering

21. Importance of Lifecycle Models • Provide guidance for project management • what major tasks should be tackled next? milestones! • what kind of progress has been made? • The necessity of lifecycle models • character of software development has changed • early days: programmers were the primary users • modest designs; potential of software unknown • more complex systems attempted • more features, more sophistication  greater complexity, more chances for error • heterogeneous users Software Engineering

22. Life Cycle Models: Summary [1] • Build and fix: Acceptable for short programs that do not require maintenance. • Waterfall: Disciplined approach, document driven; delivered product may not meet client needs. • Rapid prototyping: Ensures that delivered product meets client needs; might become a build-and-fix model. • Incremental: Maximizes early return on investment; requires open architecture; may degenerate into build-and-fix. Software Engineering

23. Life Cycle Models: Summary [2] • Spiral: Risk driven, incorporates features of the above models; useful for very large projects • UDP: Iterative, supports OO analysis and design; may degenerate into code-a-bit-test-a-bit. Software Engineering