1. Introduction to Software Engineering
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. Descriptive information
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.
Instructions
Data structures
Descriptive information

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. System software

11. Embedded software

12. Product-line software

13. Web applications

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

16. 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
Communication
Planning
Modeling
Construction
Deployment

19. Communication
Project Initiation

20. Planning
Scheduling
Tracking
Estimation

21. Modeling

22. Construction

23. Deployment

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

25. 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).

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

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

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

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

30. The Reason It All Exists
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 !

32. 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.

33. 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.

34. 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.

35. A GENERIC PROCESS MODEL
A software process framework

37. Process flow

38. Defining a Framework Activity Identifying a Task Set Process Patterns
Proven solutions
Process related problems
Pattern Name:
Forces:
Type:
Task pattern: Action & work task for s/w process (Requirement Gathering)
Stage pattern: Incorporates the multiple task pattern (Communication)
Phase pattern: Define the sequence of framework activity (Spiral model)

39. 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

42. PRESCRIPTIVE PROCESS MODELS
1. The Waterfall Model

44. Disadvantages of waterfall model:
This model is simple and easy to understand and use.
It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
In this model phases are processed and completed one at a time. Phases do not overlap.
Waterfall model works well for smaller projects where requirements are very well understood.
Disadvantages of waterfall model:
Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.
No working software is produced until late during the life cycle.
High amounts of risk and uncertainty.
Not a good model for complex and object-oriented projects.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements are at a moderate to high risk of changing.

45. PRESCRIPTIVE PROCESS MODELS
2. Incremental Process Models

47. Advantages of Incremental model: Disadvantages of Incremental model:
Generates working software quickly and early during the software life cycle.
This model is more flexible – less costly to change scope and requirements.
It is easier to test and debug during a smaller iteration.
In this model customer can respond to each built.
Lowers initial delivery cost.
Easier to manage risk because risky pieces are identified and handled during it’d iteration.
Disadvantages of Incremental model:
Needs good planning and design.
Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.
Total cost is higher than waterfall.

48. PRESCRIPTIVE PROCESS MODELS
Evolutionary Process Models
Prototyping

50. PRESCRIPTIVE PROCESS MODELS
II. The Spiral Model

52. Concept Development
System Development
System Enhancement
System Maintenance

53. Advantages of Spiral model: Disadvantages of Spiral model:
High amount of risk analysis hence, avoidance of Risk is enhanced.
Good for large and mission-critical projects.
Strong approval and documentation control.
Additional Functionality can be added at a later date.
Software is produced early in the software life cycle.
Disadvantages of Spiral model:
Can be a costly model to use.
Risk analysis requires highly specific expertise.
Project’s success is highly dependent on the risk analysis phase.
Doesn’t work well for smaller projects.

54. PRESCRIPTIVE PROCESS MODELS
4. Concurrent Models

55. 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

56. 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

57. 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)

58. 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

59. 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

60. 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

61. 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.

62. 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.

63. 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.

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

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

67. The XP Process
Planning
Design
Coding
Testing

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

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