1. Introduction to Software Engineering - Prof. Prasad Mahale
UNIT-I
Introduction to Software Engineering
- Prof. Prasad Mahale

2. Syllabus Nature of Software Software Process
Software Engineering Practice
Software Myths
Generic Process model
Process Assessment and Improvement
Perspective Process Models
Specialized Process Models
Personal and Team Process Models Agile Process models:
Agile process
Extreme programming

3. Nature of Software Delivers Computing potential
It resides on various resources
Delivers imp product Time : Information
Gateway to worldwide information
Sophistication & complexity
Adoption of software engg practice

4. Defining Software Software is:
instructions (computer programs) that when executed provide desired features, function, and performance
data structures that enable the programs to effectively manipulate information, and
descriptive information in both hard copy and virtual forms that describes the operation and use of the programs.

5. software characteristics
Software is developed or engineered; it is not manufactured in the classical sense.
Although the industry is moving toward component-based construction, most software continues to be custom built.
Software doesn’t “wear out.” But it does deteriorate!

6. Figure 1: Failure curve for hardware
Figure 1.2: Failure curves for software

7. Software Application Domains
System software
Application software
Engineering/scientific software
Embedded software
Product-line software
Web applications
Artificial intelligence software

8. Legacy Software
Legacy software systems were developed decades ago
Continually modified to meet changes
Must be adopted
Enhance to implement

9. THE SOFTWARE PROCESS
A process is a collection of activities, actions, and tasks that are performed when some work product is to be created.
A generic process framework for software engineering encompasses five activities:
Communication
Planning
Modeling
Construction
Deployment

12. Communication
Project Initiation

13. Planning
Scheduling
Tracking
Estimation

14. Modeling

15. Construction

16. Deployment

17. Umbrella activities Software project tracking and control
Risk management
Technical reviews
Measurement
Software configuration management
Reusability management
Work product preparation and production

18. SOFTWARE ENGINEERING PRACTICE
The Essence of Practice
Understand the problem (communication and analysis).
Plan a solution (modeling and software design).
Carry out the plan (code generation).
Examine the result for accuracy (testing and quality assurance).

19. Understand the problem
Who Stake Solution?
What Unknowns?
Can Compartmentalized?
Can Represent Graphically

20. Plan a solution Have u seen similar problem?
Has similar problem solved?
Can sub problems defined?
Can represent solution effective implementation?

21. Carry out the plan Does solution conforms plan?
Is component part achieved correct?

22. Examine the result for accuracy
Is it possible to test?
Does solution produce required result?

23. General Principles The Reason It All Exists Keep It Simple, Stupid!
Maintain the Vision
What You Produce, Others Will Consume
Be Open to the Future
Plan Ahead for Reuse
Think!

24. SOFTWARE MYTHS Management myths
Myth: We already have a book that’s full of standards and procedures for building software. Won’t that provide my people with everything they need to know?
Myth: If we get behind schedule, we can add more programmers and catch up (sometimes called the “Mongolian horde” concept).
Myth: If I decide to outsource the software project to a third party, I can just relax and let that firm build it.

25. 2. Customer myths
Myth: A general statement of objectives is sufficient to begin writing programs—we can fill in the details later.
Myth: Software requirements continually change, but change can be easily accommodated because software is flexible.

26. Practitioner’s myths
Myth: Once we write the program and get it to work, our job is done.
Myth: Until I get the program “running” I have no way of assessing its quality.
Myth: The only deliverable work product for a successful project is the working program.
Myth: Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.

27. A GENERIC PROCESS MODEL
A software process framework

28. Process flow

29. Defining a Framework Activity Identifying a Task Set Process Patterns
Proven solutions
Process related problems
Pattern Name:
Forces:
Type:
Stage pattern
Task pattern
Phase pattern

30. PROCESS ASSESSMENT AND IMPROVEMENT
Standard CMMI Assessment Method for Process Improvement (SCAMPI)
CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
SPICE (ISO/IEC15504)
ISO 9001:2000 for Software

31. PRESCRIPTIVE PROCESS MODELS
1. The Waterfall Model

32. PRESCRIPTIVE PROCESS MODELS
2. Incremental Process Models

33. PRESCRIPTIVE PROCESS MODELS
Evolutionary Process Models
Prototyping

35. PRESCRIPTIVE PROCESS MODELS
II. The Spiral Model

36. PRESCRIPTIVE PROCESS MODELS
4. Concurrent Models

37. SPECIALIZED PROCESS MODELS
Component-Based Development
Provide targeted functionality
Incorporates characteristics of spiral model
Model construct applications
Researched and evaluated for application
Design to accommodate components
Integrated into architecture
Testing ensured proper functionality

38. SPECIALIZED PROCESS MODELS
The Formal Methods Model
Leads to mathematical specification
Mechanism for eliminating many problems
Quite time consuming and expensive
Difficult to use the models as communication mechanism

39. SPECIALIZED PROCESS MODELS
Aspect-Oriented Software Development
Implement a set of localized feature, fun, info
Modeled as a component (OO class)
High level properties (eg. Security & fault tolerence)
Sophisticated concern
Crosscutting concern(fun, feature, info)

40. PERSONAL AND TEAM PROCESS MODELS
Personal Software Process (PSP)
The PSP model defines five framework activities
Planning
High-level design
High-level design review
Development
Postmortem

41. Team Software Process (TSP)
Build self directed teams that plan and tract the work
Integrated product team 3 to 20 enggs
Show managers how to motivate their teams
Accelerate software process improvements
Facilitate university teaching of industrial team grade skills
Define roles and responsibility for each team members
Track, manages and report project status

42. AGILE PROCESS MODELS
Agile process engineering combines a philosophy and a set of development guidelines.
The philosophy encourages customer satisfaction and early incremental delivery of software, small highly motivated project teams, informal methods, minimal software engineering products, and overall development simplicity.
The development guidelines stress delivery over analysis and design and active and continuous communication between developer and customer

43. Agility Principles
The Agile Alliance defines agility principles for those who want to achieve agility:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.

44. Build projects around motivated individuals
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity—the art of maximizing the amount of work not done—is essential.

45. The Politics of Agile Development
This methodology debate risk degenerating into a religious war.
The real que is: what is the best to achieve it
Each model there is a set of ideas
Many agile concepts are simply adaptations of good s/w engg.

46. Human Factors: Competence Common focus Collaboration
Decision-making ability
Fuzzy problem-solving ability
Mutual trust and respect
Self-organization

47. EXTREME PROGRAMMING (XP)
XP Values
Communication
Simplicity
Feedback
courage

49. The XP Process
Planning
Design
Coding
Testing

51. Industrial XP Readiness assessment Project community
Project chartering
Test-driven management
Retrospectives
Continuous learn

53. The XP Debate Requirements volatility Conflicting customer need
Requirements are express informally
Lack of formal design