UNITI Introduction to Software Engineering Prof Prasad Mahale

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

Syllabus A. B. C. D. E. F. G. H. I. J. K. Nature of 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

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

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

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

Figure 1: Failure curve for hardware Figure 1. 2: Failure curves for software

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

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

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 Project Initiation

Planning Estimation Scheduling Tracking

Modeling

Construction

Deployment

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

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

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

Plan a solution ilar n sim e e s u Have m? e l b o r p Has similar problem solved? Can sub problems defined? Can re effecti present solu ve imp t lemen ion tation ?

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

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

ü General Principles 1. The Reason It All Exists 2. Keep It Simple, Stupid! 3. Maintain the Vision 4. What You Produce, Others Will Consume 5. Be Open to the Future 6. Plan Ahead for Reuse 7. Think!

SOFTWARE MYTHS 1. 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.

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.

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

A GENERIC PROCESS MODEL A software process framework

Process flow

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

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

PRESCRIPTIVE PROCESS MODELS 1. The Waterfall Model

PRESCRIPTIVE PROCESS MODELS 2. Incremental Process Models

PRESCRIPTIVE PROCESS MODELS 3. Evolutionary Process Models I. Prototyping

PRESCRIPTIVE PROCESS MODELS II. The Spiral Model

PRESCRIPTIVE PROCESS MODELS 4. Concurrent Models

SPECIALIZED PROCESS MODELS q 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

SPECIALIZED PROCESS MODELS q 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

SPECIALIZED PROCESS MODELS q 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)

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

q 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

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

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.

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

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.

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

EXTREME PROGRAMMING (XP) q XP Values § Communication § Simplicity § Feedback § courage

q. The XP Process § Planning § Design § Coding § Testing

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

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