UNIT I Introduction to Software Engineering

Presented By

Prof.Hitesh Mohapatra Dept. of Computer Engg.

Softwares Dual Role

Software is a product

Delivers computing potential Produces, manages, acquires, modifies, displays, or transmits information Supports or directly provides system functionality Controls other programs (e.g., an operating system) Effects communications (e.g., networking software) Helps build other software (e.g., software tools)

Software is a vehicle for delivering a product

What is Software?
Software is a set of items or objects that form a configuration that includes programs documents data ...

What is Software?

software is engineered software doesnt wear out software is complex

Wear vs. Deterioration

Software Applications

system software application software engineering/scientific software embedded software product-line software Web Apps (Web applications) AI software

SoftwareNew Categories

Ubiquitous computingwireless networks Net sourcingthe Web as a computing engine Open sourcefree source code open to the computing community (a blessing, but also a potential curse!) Also (see Chapter 32)

Data mining Grid computing Cognitive machines Software for nanotechnologies

Legacy Software
Why must it change?

software must be adapted to meet the needs of new computing environments or technology. software must be enhanced to implement new business requirements. software must be extended to make it interoperable with other more modern systems or databases. software must be re-architected to make it viable within a network environment.

Software Myths

Management Myths

We have books of standards, my staff will have sufficient info. I work very hard to put the latest, greatest, fastest, state-of-the-art hardware in front of all my programmers. We have the greatest CASE tools around. If we get behind, we can just add more programmers. A general statement of objectives is sufficient to start coding, fill in the details later. Project requirements change constantly, but change is easy because software is flexible. Once the program is written and working, our job is done. Until the program is running, there is no way to assess quality. The only deliverable for a successful project is the working program.

Customer myths

Programmer myths

Software Engineering Practice

Software engineering practice - Communication practices - Planning practices - Analysis modeling practices - Design modeling practices - Construction practices - Deployment practices
-

Software Engineering Practice

Consists of a collection of concepts, principles, methods, and tools that a software engineer calls upon on a daily basis Equips managers to manage software projects and software engineers to build computer programs Provides necessary technical and management how tos in getting the job done Transforms a haphazard unfocused approach into something that is more organized, more effective, and more likely to achieve success

The Essence of Problem Solving

1)

Understand the problem (communication and analysis)

Who has a stake in the solution to the problem? What are the unknowns (data, function, behavior)? Can the problem be compartmentalized? Can the problem be represented graphically?

2)

Plan a solution (planning, modeling and software design)

Have you seen similar problems like this before? Has a similar problem been solved and is the solution reusable? Can sub problems be defined and are solutions available for the sub problems?

The Essence of Problem Solving (continued)

3)

Carry out the plan (construction; code generation)

Does the solution conform to the plan? Is the source code traceable back to the design? Is each component of the solution correct? Has the design and code been reviewed?

4)

Examine the results for accuracy (testing and quality assurance)

Is it possible to test each component of the solution? Does the solution produce results that conform to the data, function, and behavior that are required?

Seven Core Principles for Software Engineering

1)

Remember the reason that the software exists

The software should provide value to its users and satisfy the requirements All design and implementation should be as simple as possible

2) 3) 4)

Keep it simple, stupid (KISS)

Maintain the vision of the project

A clear vision is essential to the projects success

Always specify, design, and implement knowing that someone else will later have to understand and modify what you did

Others will consume what you produce

5)

Be open to the future

Never design yourself into a corner; build software that can be easily changed and adapted
Reuse of software reduces the long-term cost and increases the value of the program and the reusable components Placing clear, complete thought before action will almost always produce better results

6)

Plan ahead for software reuse

7)

Think, then act

Communication Practices
(Requirements Elicitation)
Communication Project initiation Requirements gathering Planning Estimating Scheduling Tracking

Modelling Analysis Design Construction Code Test Deployment Delivery Support Feedback
15

Communication Principles
1) 2) 3) 4) 5) 6) 7) 8) 9)

10)

Listen to the speaker and concentrate on what is being said Prepare before you meet by researching and understanding the problem Someone should facility the meeting and have an agenda Face-to-face communication is best, but also have a document or presentation to focus the discussion Take notes and document decisions Strive for collaboration and consensus Stay focused on a topic; modularize your discussion If something is unclear, draw a picture Move on to the next topic a) after you agree to something, b) if you cannot agree to something, or c) if a feature or function is unclear and cannot be clarified at the moment Negotiation is not a contest or a game; it works best when both parties win

Planning Practices (Defining a Road Map)

Communication Project initiation Requirements gathering Planning Estimating Scheduling Modelling Tracking Analysis Design

Construction Code Test

Deployment Delivery Support Feedback

17

Planning Principles
1) 2)

3)
4) 5) 6) 7) 8) 9) 10)

Understand the scope of the project Involve the customer in the planning activity Recognize that planning is iterative; things will change Estimate based only on what you know Consider risk as you define the plan Be realistic on how much can be done each day by each person and how well Adjust granularity as you define the plan Define how you intend to ensure quality Describe how you intend to accommodate change Track the plan frequently and make adjustments as required

Barry Boehms W5HH Principle

Why is the system being developed? What will be done? When will it be accomplished? Who is responsible for each function? Where are they organizationally located? How will the job be done technically and managerially? How much of each resource is needed?

The answers to these questions lead to a definition of key project characteristics and the resultant project plan.

Modeling Practices (Analysis and Design)

Communication Project initiation Requirements gathering Planning Estimating Scheduling Tracking

Modelling Analysis Design

Construction Code Test Deployment Delivery Support Feedback

Analysis Modeling Principles

1)
2) 3) 4)

5)

The information domain of a problem (the data that flows in and out of a system) must be represented and understood The functions that the software performs must be defined The behavior of the software (as a consequence of external events) must be represented The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion The analysis task should move from essential information toward implementation detail

Design Modeling Principles

1)

2)
3) 4) 5) 6) 7) 8) 9)

The design should be traceable to the analysis model Always consider the software architecture of the system to be built Design of data is as important as design of processing functions Interfaces (both internal and external) must be designed with care User interface design should be tuned to the needs of the end-user and should stress ease of use Component-level design should be functionally independent (high cohesion) Components should be loosely coupled to one another and to the external environment Design representations (models) should be easily understandable The design should be developed iteratively; with each iteration, the designer should strive for greater simplicity

External quality factors: those properties that can be readily observed

Internal quality factors: those properties that lead to a high-quality design from a technical perspective

Construction Practices
Communication Project initiation Requirements gathering

Planning Estimating Scheduling Tracking

Modelling Analysis Design

Construction Code Test Deployment Delivery Support Feedback

Coding Principles
(Preparation before coding)
1) 2) 3) 4) 5)

Understand the problem you are trying to solve Understand basic design principles and concepts Pick a programming language that meets the needs of the software to be built and the environment in which it will operate Select a programming environment that provides tools that will make your work easier Create a set of unit tests that will be applied once the component you code is completed

Coding Principles
(As you begin coding)
1) 2) 3) 4) 5) 6) 7) 8)

Constrain your algorithms by following structured programming practices Select data structures that will meet the needs of the design Understand the software architecture and create interfaces that are consistent with it Keep conditional logic as simple as possible Create nested loops in a way that makes them easily testable Select meaningful variable names and follow other local coding standards Write code that is self-documenting Create a visual layout (e.g., indentation and blank lines) that aids code understanding

Coding Principles
1) 2) 3)

Conduct a code walkthrough Perform unit tests (black-box and white-box) and correct errors you have uncovered Refactor the code

(After completing the first round of code)

Testing Principles
1) 2) 3)

All tests should be traceable to the software requirements Tests should be planned long before testing begins The Pareto principle applies to software testing
80% of the uncovered errors are in 20% of the code

4)

Testing should begin in the small and progress toward testing in the large
Unit testing --> integration testing --> validation testing --> system testing

5)

Exhaustive testing is not possible .

Test Objectives
1) 2) 3)

Testing is a process of executing a program with the intent of finding an error A good test case is one that has a high probability of finding an asyet undiscovered error A successful test is one that uncovers an as-yet undiscovered error

Deployment Practices
Communication Project initiation Requirements gathering Planning Estimating Scheduling Tracking Modelling Analysis Design Construction Code Deployment Test Delivery Support Feedback

Deployment Principles
1)

Customer expectations for the software must be managed

Be careful not to promise too much or to mislead the user

2) 3) 4)

5)

A complete delivery package should be assembled and tested A support regime must be established before the software is delivered Appropriate instructional materials must be provided to end users Buggy software should be fixed first, delivered later

Software Process

Process Models

Waterfall model Incremental Process Models

Rapid application development model Incremental model

Prototyping model Spiral model Component-Based Development Formal Method model

Evolutionary Process Models

Specialized Process Models

Comparison of life-cycle models

Waterfall model

Requirements are reasonably understood. When work flow is linear in fashion Systematic sequential approach

Incremental model

Evolution of waterfall model New features added to 1st Increment(core product) Incremental software development model may be applicable to projects where:

Software Requirements are well defined, but realization may be delayed. The basic software functionality are required early

SW Functionality and features Time

Inc 1

Inc 2

Inc 3

RAD Model

Rapid Application Development Short development cycle Faster development (60-90) days High quality results Use of (CASE) Tools Component based construction System delivered in short time (2 to 3 months) Useful where requirements are well understood and scope is limited

The RAD Model

Team # n
M o d e lin g
business m odeling dat a m odeling process m odeling

C o n s t r u c t io n

Com m unicat ion

Team # 2
Mo d eling
b u si n e ss m o d e l i n g dat a m odeling p ro ce ss m o d e l i n g

com ponent reuse aut om at ic code generat ion t est ing

Planning
Co nst r uct io n

De ploym e nt
int egrat ion deliv ery feedback

Team # 1 Mode ling

business modeling dat a modeling process modeling

co m p o n e n t re u se a u t o m a t i c co d e g e n e ra t i o n t e st i n g

Const r uct ion

component reuse aut omat ic code generat ion t est ing

6 0 - 9 0 days

40

Process Models

Waterfall model Incremental Process Models

Rapid application development model Incremental model Prototyping model Spiral model Component-Based Development Formal Method model

Evolutionary Process Models

Specialized Process Models

Unified Process Comparison of life-cycle models

Prototyping

Early approximation of a final system Linear and iterative Customer is unable to define the system Requirements are not freezed a prototype is built to understand the requirements

Evolutionary Models: Prototyping

Qu ick p lan Quick

Com m unicat ion

plan

communication
Mo d e lin g Modeling Qu ick d e sig n

Quick design

Deployment Deployment De live r y delivery & & Fe e dback

feedback

Construction of of prototype pr ot ot ype

Const r uct ion

43

Spiral Model

Simplified form

Waterfall model plus risk analysis Alternatives Risk analysis Evaluation Planning of next phase

Precede each phase by

Follow each phase by

Evolutionary Models: The Spiral

planning
estimation sch eduling risk analysis

communication modeling
analysis design start

deployment
delivery feedback

construction
code test

45

Specialized Process Models 1)Component Based Development

COTS

Commercial off-the-shelf software components developed by vendors who offer them as products.

Decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components.

2) Formal Methods Model

Mathematically based techniques for representing and analysis of software. Formal methods include

Formal specification Specification analysis and proof Transformational development Program verification

Formal Methods Model

Reduces requirements errors as it forces a detailed analysis of the requirements Incompleteness and inconsistencies can be discovered and resolved Currently very time consuming and expensive Extensive training required Difficult to use this model to communicate with the customer.

Unified Process

Contains features of OOA and OOD. UML- Unified Modeling Language

It was created to support the OO design and modeling.

iterative and incremental process

Phases of Unified process

All the phases are concurrent in nature Inception Elaboration Construction Transition Production

The Unified Process (UP)

Elab o r at io n elaboration Incep t inceptionio n

inception

co nst r uct io n
Release
soft ware increment

t r ansit io n

p r o d uct io n
52

UP (contd)

Inception

Customer communication Planning

Identify resources, assess risks, defines schedule In the form of use cases. A tentative outline of major sub-systems, functions and features that populate them.

Business requirements are identified

Rough architecture

UP (contd)

Elaboration

Customer communication Modeling activity Expands the use cases. Expands the architecture to:

Use case model, analysis model, design model, implementation model and deployment model. Evaluate scope, risks, project delivery dates

Review plan and make modifications

UP (contd)

Construction

Develop software components (that make the use cases operational). Complete the analysis and design models. Implement all functions and features for that increment. Conduct unit testing for the components Integrate components.

UP (contd)

Transition

Create user manuals, guidelines, installation procedures. Software is given to users for beta testing. Get user feedback The increment is now a useable software release.

UP Work Products
Incept ion phase
Vision document Init ial use-case model Init ial project glossary Init ial business case Init ial risk assessment . Project plan, phases and it erat ions. Business model, if necessary . One or more prot ot y pes
I nc e pt i o n

Elaborat ion phase

Use-case model Supplement ary requirement s including non-funct ional Analy sis model Soft ware archit ect ure Descript ion. Execut able archit ect ural prot ot y pe. Preliminary design model Rev ised risk list Project plan including it erat ion plan adapt ed workflows milest ones t echnical work product s Preliminary user manual

Const ruct ion phase

Design model Soft ware component s Int egrat ed soft ware increment Test plan and procedure Test cases Support document at ion user manuals inst allat ion manuals descript ion of current increment

Transit ion phase

Deliv ered soft ware increment Bet a t est report s General user feedback

57

Agile Software Development

Is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Self Organization: is the process where a structure or pattern appears in a system without central authority. Cross-Functional team : is a group of people with different functional expertise working toward a common goal.

Extreme Programming

Is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. It releases product in short development cycles (time boxing) Pair Programming: Driver and Observer Time Boxing Code Review Unit Testing