Welcome to ECSE-6770 Software Engineering Convenor: Houman Younessi Tel: 860-548-7880

1. Introduction Welcome to ECSE-6770 Software Engineering Convenor: Houman Younessi Tel: 860-548-7880 Email: youneh@rpi.edu

2. Introduction Aims and Objectives The major objective of this course is to construct a solid foundation for understanding and application of principles, techniques and technologies utilized in the development of good software systems by individuals or teams. Upon successful completion of the course the student should be able to identify and utilize a wide array of principles and techniques and technologies of software engineering in order to create or alter reasonably sophisticated software systems. The emphasis is on object-oriented and other modern approaches and ideas in software engineering but not to the detriment and neglect of more traditional frameworks.

3. Software What is software? The three views of software: Source code Executable Simulation The two types of software: System Software Application Software

4. Software The two kinds of software: Generic or packaged Software Custom-made software The two forms of software: Open source software Closed source software

5. Functionality Efficiency Reliability Portability Learnability Security Maintainability Usability Software Irrespective of all this we expect all software products to possess a sufficient level of: Quality

6. Software Development To build software that has a chance of possessing a sufficient level of quality, we must: Understand the problem situation and its requirements Propose a number of solutions to the problem and select the most appropriate Implement that solution Ensure that the solution as implemented solves our problem adequately Ensure that the solution continues to solve our problem for the foreseeable future even if the problem somewhat changes.

7. Software Development These activities in turn are called: Requirements Analysis and Specification Design Implementation Verification and Validation Maintenance These are the basic activities of software development

8. Software Engineering “The establishment and use of sound engineering principles in order to obtain economically, software that is reliable and works efficiently on real machines” (Naur, 1969) More of goal than a definition “The theories, methods and tools which are needed to develop software for computers” (Sommerville, 1995) Operational, but does not highlight the quantitative and scientific underpinnings required of an “engineering” discipline.

9. Software Engineering Software Engineering is our continued effort against the software crisis. Software Engineering is the collective term applied to attempts to produce high quality, complex and large software on a largely methodical, and reasonably sustainable basis with an increasingly scientific and quantitative orientation.

10. Software Engineering To do so, SE relied and continues to rely on three principle approaches of: Improving the management of the software process Establishment of a rigorous foundation for the software process Utilization of technology to support the software process This defines the three dimensions of People and context, Methodology, and Technology.

11. Software Process Frameworks If you are on a good thing, stick with it. We define frameworks, if you like methods or approaches, for a lot of what we do. So do we also in SE. We define a software process (sometimes called a methodology or method although these terms are not accurate) as a process of developing a piece of software or a process of getting through a software development project. Why?

12. Software Process Frameworks What characteristics should these frameworks have: Understandable Enactable (instantitable) Repeatable Definable (well defined) Manageable (well managed) Improvable

13. Software Process Frameworks Requirements Analysis The Waterfall Model System Design First presented in 1970 by Royce, it is a simple transformationally based lifecycle model depicting a sequential execution of the principle “stages” of the development process. Program Design Coding Unit and Integra-tion testing System Testing Acceptance Testing Operation and Maintenance

14. Software Process Frameworks The V- Model A variation of the Waterfall model, the process framework can be viewed as several process layers (horizontal) each depicting a level of abstraction, and three process partitions each depicting a major class of process activity: Production, Evaluation and Operation.

15. Software Process Frameworks Operation Evaluation Creation System Req. Analysis Operation and Maintenance Acceptance Testing Software Req. Elicitation Requirements Analysis System Testing Component Integration Testing High level Design Detailed Design Unit Testing The V- Model Implementation

16. Software Process Frameworks The Spiral Model First introduced by Boehm (1988), it views the software process as a series of risk management cycles. As we move away from the origin, the level of funds expended increase and as we go through each quadrant, we deal with a specific set of activities. Hopefully, after a sufficient number of cycles, the product will be accepted. The spiral model is based on the notion of prototyping.

17. Software Process Frameworks The Spiral Model

18. Software Process Frameworks The Fountain Model

19. Software Process Frameworks The Rational Unified Process (RUP) Model This model is described as an architecture centric, use-case driven, workflow based model. Architecture Centric: Programmers Software Management End User Functionality Implementation View Logical View Analysts/Testers Behavior/Quality Use-Case View Process View Deployment View System Integrators Performance Scalability System Engineers Delivery/Installation

20. Software Process Frameworks Use-Case Driven

21. Software Process Frameworks Workflow Based: An example of a workflow depiction: Workflow in Requirements

22. Software Process Frameworks OPEN Model The Object-oriented Process, Environments, and Notation (OPEN) is a Software Engineering Process Architecture (SEPA) that may be instantiated to yield Software Process Frameworks (such as RUP). OPEN has an architectural basis that is built upon: Business Strategy Business Processes Business Components, and Technical Infrastructure

23. Software Process Frameworks OPEN Model The model is also based on the interrelation between: Activities Tasks, and Techniques Each one of which might yield (usually does) at least one work-product.

24. Software Process Frameworks OPEN Model All activities, tasks and techniques are defined in terms of a precise process definition template. Activities and tasks on the one hand and tasks and techniques on the other are related with each other using a deontic grid indicating when each elements may be used in relation to another and when not. Given this infrastructure, the model may be represented flexibly and in terms of contracts.

25. Software Process Frameworks      Initiate Project Plan Programme Req. Engineering Analysis and Model Refinement Plan Resources Conduct Domain Modeling Plan Project Conduct Evolutionary Development: OOA,OOD,OOP,V+V Acquire Knowledge from Other Projects Review with Users Build Fix Bugs Plan Implementation Use System Evaluate

26. Software Process Frameworks OPEN Model • Short-term Planning • Project Conduct • Long-Term Logistics • Long-Term Planning • System Utilization

27. Software Processes Enaction or Instantiation Software Process Frameworks do not model an individual process. They are a template for processes. An individual instance, or enaction of a software process framework is called a Software Process. We should be able to follow a software process to complete a software development project.

28. Software Processes A software process must have many characteristics. The most important of which are: Functionality (appropriateness) Clarity (of definition) Usability Usability and functionality are obvious. For clarity, a software process must possess some qualities.

29. Software Processes Firstly a software process (for that matter the framework that yielded it) should reflect all three major concerns of SE: Methodology Technology, and People and context Additionally, it should provide a model of the process in terms of: Structure Transformations, and Causality

30. References • Royce, W.W.; “Managing the development of large software systems:Concepts and techniques”; Proc. WESCON; 1970. • Boehm, B.W.; “A spiral model for software development and enhancement”; IEEE Computer; Vol. 25, No. 5; 1988 • Naur, P.; Randall, B.; Baxton, J.; “Software Engineering:Concepts and Techniques”; Petrocelli-Charter; 1976. (For Naur, 1969) • Sommerville, I; “Software Engineering”; 5th ed.; Addison-Wesley; 1995. • Graham,I; Henderson Sellers, B and Younessi, H.; “The OPEN Process Specification”; Addison-Wesley; 1997 • Kruchten, P.; “The Rational Unified Rrocess: An Introduction”; Addison-Wesley, 1998. • Henderson-Sellers, B. and Edwards, J.; “BOOKTWO of Object-oriented Knowledge:The working Object”; Prentice-Hall; 1994.

31. Further Reading Younessi, H.; “Cooking up quality software”; Object Magazine; October 1997 Pressman, R.; “Software Process Perceptions”; IEEE Software, vol. 13, No 6; 1996. Wasserman, A.I.; “Towards a discipline of Software Engineering”; IEEE Software, Vol. 13, No. 6; 1996. Osterweil, L.; “Software Processes are software too”; Proc. ICSE 9; Monterey CA; 1987.