Introduction to Software Engineering

1. Introduction toSoftware Engineering

2. Definition and properties • A system is a collection of interrelated components that work together to achieve some objective • Properties : • Complex interrelationship among the parts • Reliability • Usability

3. System & its environment • We create a system to modify/adapt to the environment • There are internal & external relationships between the system and it’s environment

4. Procurement • To buy • To design from scratch • Large systems : mix of bought and designed systems • Others : really start from scratch using a development tool.

5. System customer Principal contractor Subcontractor 1 Subcontractor 1 Subcontractor 1

6. Software Engineering • “The profession concerned with creating and maintaining software applications by applying computer science, project management, domain knowledge and other skills and technologies” • “SE technologies and practices (databases, libraries, patterns, platforms, processes, etc.) help developers by improving productivity and quality”

7. SE – Pressman “An outgrowth of hardware and systems engineering. It encompasses a set of three key elements – methods, tools, and procedures -- that enable the manager to control the process of software development and provide the practitioner with a foundation for building high-quality software in a productive manner.”

8. The classic life cycle • Systems Engineering (requirements gathering) • Analysis • Design • Code • Testing • Maintenance

9. The system engineering process • Requirements definition • Systems Design • Sub-system development • System Integration • System installation • System evolution • System decommissioning

10. System requirements definition • Determine • Coarse grain functional requirements (what are the basic functions of the system) • System properties (availability, performance, safety, security) • What it should not exhibit

11. System design • Partition requirements • Identify sub-systems • assign requirements to sub-systems • Specify sub-system functionality • Define sub-system interfaces

12. Sub-system developmemt • Development of the sub-systems • Programming

13. System integration • Putting together independently development sub-systems into one coherent system

14. System Installation • Problems • Different environment in which the system is to be installed (OS, development software version) • Human resistance • Co-existence with an old system • Physical installation problems

15. Final stages • System operation • training, changing the normal work process • System evolution • feedback and changes in the environment • change is costly • System decommissioning • Putting the system out of service

16. Software Lifecycles

17. Definition Software Lifecycle refers to the progression of the software system from development through maintenance and eventually replacement. Involves the activities in the production of a software system.

18. Phases : In General • Requirements analysis and specification • Design • Preliminary Design • Detailed Design • Implementation • Testing • Unit testing • Integration Testing • System Testing • Installation and Acceptance Testing • Maintenance

19. Examples of Software Lifecycles • Waterfall model • Modified Waterfall Model • Prototyping • Boehm’s Spiral model • Object-Oriented Analysis

20. Waterfall Model • Derived from other engineering processes in the ‘70s • Offered a means of making the development process more structured • Expresses the interaction between subsequent phases • Each phase cascades into the next • Original WM : • A strict sequence was implied • Did not provide feedback

21. Modified Waterfall Model • Need to provide for overlap and feedback between phases • It is iterative compared to the linear model of the original WM • Verification and validation are added • Verification checks that the system is correct • Validation checks that the system meets the users desires

22. Comments on WM • Inflexible in the partitioning of the project in distinct phases • Reflect common engineering practices • Emphasis • Discerning the users needs and requirements prior to the system being built • Agreement bet. User and developer with respect to the requirements

23. Comments on WM • Exclusively document-driven models • Some facts • 50% of the design effort occurs during the actual design phase • 1/3 of the design effort done in the coding activity • 16% of the design effort occurs after the system is supposed to be completed • People using this type of model are opportunistic. There is a need for strictness and signoffs in terms of documentation

24. Prototyping • Aims to enhance the accuracy of the designers perception of the user’s requirements • Develop an initial system for user feedback and then refine by developing a lot of versions until a satisfactory system emerges • Rapid development is the key

25. Types • Exploratory • Start with parts which are understood and then evolves as the user proposed new features • Throw Away • Focus is more on poorly understood concepts

26. Comments • Took 40% less time and 45% less code • Produced code which is not as robust and more difficult to maintain • Less documentation is present

27. Boehm’s Spiral Model • An improved model where all generic models have been considered • Boehm proposed a spiral model where each round of the spiral • Identifies the subproblem which has the highest risk associated with it • Finds a solution to that problem

28. Object Oriented Analysis • Activities • Object-oriented analysis • Object-oriented design • Object-oriented programming • Main difference between the other models : Modeling of the system components using object-oriented concepts and techniques in programming.

29. Planning and Cost Estimation

30. Planning • All software development should be planned, including analysis and assessment • Provides a means for effective management of a software project -- identifies problems and possible solutions • Involves • Delivery date • Available Staff • Budget • Staff Expense

31. Estimates • Project Structure • Project Size • Functions and their hierarchical relationships

32. Project Plan Indicates available resources, work breakdown and a schedule for completion

33. Documentation • Introduction • Describe objectives and constraints • Organization • Team organization, team roles, team members • Risk Analysis • Describe possible risks and solutions • Resource requirements • Hardware and Software

34. Documentation • Work Breakdown • Composed of activities, milestones, tasks and deliverables • Milestones : ending point for a SW activity • Milestones are composed of tasks • Deliverables : To be given to the customer • Schedule • Reporting Mechanisms • Management reports required and their due dates

35. Project Scheduling • Difficult and dependent on the experience of the project manager • Initially optimistic • Do not only estimate time, but also resources like people and equipment

36. Cost Estimation • Like Project scheduling, is also dependent on the PM’s experience • A lot of cost estimation techniques and a lot of companies have their own charts in estimating cost and what consists of costs

37. Types of estimation • Algorithmic Cost modeling • Uses historical cost which relates software size to cost • Expert judgement • Experts estimate how much the proj. will cost and then it is discussed • Estimation by analogy • Uses other similar projects as basis

38. Types of estimation • Parkinson’s Law • “Work expands to fill the time available” • Cost is determined by available resources rather than by objective assessment • 12 mo x 5 people = 60 person-months • Pricing to Win • Based on the customer’s budget

39. COCOMO Model • Algorithmic approach • Well documented and one of more widely used cost-estimation models • Based on the model : Effort = C* PM ^s * M C is complexity of the project, PM is some product metric (usually # of lines); M is a multiplier; and s indicates the increasing effort for large proj. (< 1)

40. The formula • Basic • Well understood application developed by small teams. PM = 2.4(KDSI)^1.05 * M • Moderate • More complex projects whose team members have limited experience PM = 3.0(KDSI)^1.12*M

41. The formula • Embedded • Complex proj. where the software is part of the a strongly integrated set of HW, SW, regulations and procedures PM=3.6(KDSi)^1.20*M

42. Requirements Analysis & Specification

43. Notes • The WHAT phase rather than a HOW phase • WHAT are the user’s needs, WHAT is the current system, WHAT are the constraints on the current and future system • Both FUNCTIONAL (describing function or service) and non-functional (time, money, OS platform)

44. Document • Output : Requirement Specification Document • Idea : Reflects a mutual understanding between client and developer of the work to be completed • Provides the basis for acceptance testing (did we create the right system?)

45. Characteristics • Unambiguous • Complete • Verifiable • Consistent • Modifiable • Traceable • Useable

46. Stages • Feasibility Study • Requirements Analysis • Requirements Definition • Requirements Specification

47. Feasibility Study Evaluates the ability to satisfy user needs using current software and hardware technologies and the constraints of the user’s organization (like manpower, budgetary constraints)

48. Requirements Analysis • Provides a statement of the requirements of the problem • Analyzes the current situation • States the goals of the system being developed (cut costs, reduce errors, etc.) • Answers are acquired via interviews, observations, • Read by : client managers, end users, client engineers, contractors, development architects

49. Q in RA • Who is involved and what are their background • What is the current system (equipment constraints) • What functions will be incorporated? • When must the system be completed? (schedule) • What is the impact on personnel, training, etc. • Why is the new system being developed? • What are the constraints in terms of cost?

50. Requirements Specification • Details what the system will do • Determines what the operational constriants are • It should • Completely specify technical requirements • Specify constraints and functions • Specify what should be done in exceptional cases • Specify performance requirements