Software engineering Dr.

Jayashree R

Unit-1

Introduction

- Software: collection of executable computer programs, con guration les and

associated libraries, and documentation

- Software product: software for speci c group of requirements

• Generic, custom, system, application, etc

- Engineering: acquiring and using well de ned scienti c principles and

systematic methods for developing products with economic sense, social
perspective and practical considerations

- Software engineering
• Systematic, disciplined, quanti able approach towards development,
operation and maintenance

• Software product developed via SE principles has higher probability of being

reliable

• Usage of appropriate tools and techniques

• Focus more on techniques for developing and maintaining software

Fundamental drivers of SE

- Industrial strength software:

• Needs to be

- Operational: functionality, usability, correctness

- Capable of being moved: portability, interoperability

- Maintainable: modularity, maintainability, scalability

• Elaborate documentation

• Absence/minimal bugs
• Impactful to business’s; quality and resilience

- Software is expensive
• Labour intensive

1 Teaching Assistant: Aanchal Narendran

fi
fi
fi
fi
fi
fi
 Software engineering Dr. Jayashree R
• Software has lot of maintenance and rework

- Maintenance: corrective, adaptive or rework

- Costs of hardware and software maintenance

- Late and unreliable

• Typically 35% projects are runaway

• 70% of equipment failure in defence is due to software

- Can in uence the life and death of a person

- Heterogeneity: systems operate as distributed systems across networks

- Diversity: many types of software systems with di erent techniques and methods

- Business and social change

• Change existing and develop new software

- Security and trust

- Scale
- Quality and Productivity

- Consistency and repeatability

Software Lifecycle

- Software Process/Lifecycle/Process model/lifecycle model:

• Structured set of activities producing intermediate and nal products

• Each step has a guiding principle that explains the goals of each phase

- Products: outcomes of executing a process

- Each phase has the following characteristics

• Entry criteria: conditions satis ed for initiating this phase

• Task and its deliverables

• Exit criteria
• Who is responsible
• Dependencies

2 Teaching Assistant: Aanchal Narendran

fl
fi
ff
fi
Software engineering Dr. Jayashree R
• Constraints

- Software Development Life Cycle (SDLC)

• Systematic process for building software that ensures quality and

correctness that meets customers business requirements

• Stages
- Requirement analysis:

• Entry Criteria: Need for a solution to existing problem

• Task and Deliverables: clearer picture of scope of project, anticipate

issues and opportunities

- Detailed requirements to draft a timeline

• Exit Criteria: Software Requirement Speci cation document

- Everything designed and developed

• Who is Responsible: Senior Team members, Stakeholders and Domain
Experts

• Feasibility Study: In terms of Economy, Legal, Operations, Technical

and Schedule

- Design
• Entry Criteria: Preparation of Software Requirement Speci cation

• Task and Deliverables: prepare system and software design documents

3 Teaching Assistant: Aanchal Narendran

fi
fi
 Software engineering Dr. Jayashree R
- De ne overall architecture

• Exit Criteria: Preparation of two design documents

- High Level Design: brief description and name of each module

• Outlines functionality
• Interface relationship and dependencies

- Low Level Design: Functional logic of modules

• Details of interface

• Address dependencies and errors

• Account for input and output to each module
- Implementation/Coding
• Entry Criteria: Preparation of System Design documents
• Task and Deliverable: development of modules in a programming
language

• Exit Criteria: Software

• Who is Responsible: Developers
- Testing
• Entry Criteria: developed software

• Task and Deliverable: tests functionality of entire system in accordance to

requirements

- The testing team and developers resolve any bugs

• Exit Criteria: Bug-free, stable and working software

• Who is Responsible: Quality Assurance and Testing Team

- Maintenance
• Three main activities

- Bug Fixing: from scenarios that were not tested

- Upgrade: to newer versions

- Enhancement: addition of features

4 Teaching Assistant: Aanchal Narendran

fi
 Software engineering Dr. Jayashree R
- Product Development Lifecycle (PDLC)

• Speci c set of steps to take a project from rst spark to release

• Stages
- Brainstorm: ideate a product based on user problems
• Identify competitors and existing products
- Current product should ll a gap or be better
- De ne: Map out speci cations for the product

• Customers, their needs and features

• Narrow the focus of the product

- Design: development of ideas for the product

• Prototypes and wireframes to identify components

- Test: develop functional prototypes

• Three stages
- Internal tests

- Stakeholder Reviews

- External tests with potential users

• Gather and Implement feedback

5 Teaching Assistant: Aanchal Narendran

fi
fi
fi
fi
fi
Software engineering Dr. Jayashree R
- Launch: complete the product and make it accessible

- Software Maintenance Lifecycle

- Product Lifecycle

• Dictated by factors such as Market Capitalisation, Sales, Investment and so on

• Stages
- Introduction: product has been created and put on market
• Product may not be popular

- Growth: customers start to adopt product heavily

• New features may be added to be better than competitors

- Maturity: growth and adoption of the product starts plateauing

- Discontinuance: The product is not on the market but is maintained
- Obsolescence: Product is not maintained

6 Teaching Assistant: Aanchal Narendran

 Software engineering Dr. Jayashree R
- Legacy SDLCs
• Waterfall model: Each stage is executed subsequently on completion of
previous stage

- Advantages and Disadvantages

Advantages Disadvantages

Simple Assumes frozen requirements

Clear Identi ed Phases (departmentalised) Sequential and Big Bang Approach

Easy to Manage High Risk and Uncertainty

Speci c Deliverables and Review at each phase

- Usage
• For short projects where requirements are understood

• Variants at high level in large projects

• Product de nition is stable and technology understood

• Variants in large globally developed projects with other lifecycles

• V Model: Involves a Tester Lifecycle to allow testing activities to occur in

parallel

7 Teaching Assistant: Aanchal Narendran

fi
fi
fi
Software engineering Dr. Jayashree R
- Advantages and Disadvantages
Advantages Disadvantages

Similar to Waterfall Similar to Waterfall

Test Activities before Coding No early prototypes

Higher Probability of success Change in proces = Change in documentation

- Usage
• Similar to waterfall model
• Prototyping: Build throw-away and evolutionary prototypes to adapt to
change

- Relatively cheap process

- Advantages and Disadvantages

Advantages Disadvantages

Active user involvement Increased Complexity

Better Risk mitigation May not be Optimal

Earlier detection of problems and missing

functions

More Stable

• Incremental model: Model requirements are partitioned and an incremental

plan is made for delivery

8 Teaching Assistant: Aanchal Narendran

 Software engineering Dr. Jayashree R
- Working version is produced during the rst module

- Each release adds more functionality to the previous release

- Continuous integration till complete system is achieved

- Portioned requirements can have di erent development lifecycles

- Advantages and Disadvantages

Advantages Disadvantages

Earlier versions Needs good planning and design

More exible Clear and complete de nition

Easier to test Higher cost than waterfall

Reduces over-functionality

- Usage
• Projects where major requirements are de ned

• Where there is need to get product to the market early

• New tech is being used

• Resources with needed skill set are not available

• Iterative model (evolutionary): Initial implementation starts with a skeleton

followed by re nement via user feedback

- Rapid prototyping

- Advantages and Disadvantages

Advantages Disadvantages

Identify requirements Rigid with overlaps

Risk mitigation Costly system

Redesign and Rework

9 Teaching Assistant: Aanchal Narendran

fl
fi
fi
ff
fi
fi
Software engineering Dr. Jayashree R
- Usage
• Large projects

• Limitations of legacy lifecycles

- Traditional models based on predictive software development

- Upfront planning
- Suitable when there is a clear de nition of what needs to be achieved

- Do not facilitate periodic customer interactions

- Suitable for large projects with complex dependencies

- Agile
• Variety of methods that encourage

- Continual realignment of development goals with the needs and

expectations of customer

- Reduce massive planing overhead by allowing fast reactions

• Agile manifesto
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

- Focus on simplicity in both product and process

• Pros and Cons

Advantages Disadvantages

Realistic approach to development Not suitable for complex dependencies

Team work and Cross training Risk of sustainability and maintainability

Rapid Development and Demonstration Depends on customer interaction

Minimum and Flexible requirements High individual dependency

Minimal rules and easy documentation

Little to no planning

Easy to Manage and Flexible

10 Teaching Assistant: Aanchal Narendran

fi
 Software engineering Dr. Jayashree R
• Scrum Basics
- Agile methodology/frameworks

- Iterative approach towards software development

- Mechanism to apply agile practices

- Lightweight agile framework with broad applicability for managing and

controlling iterative and incremental projects

- De ned by
• Roles
- Org is split into small cross-functional, self-organising teams
- Scrum team: made up of contributors to the deliverable

• Responsible for delivering shippable increments

- Scrum master: not a manager, a facilitator

• Removes impediments and facilitates meetings

• Ensures team adheres to scrum theory and practices

- Product owner: voice/rep of the stakeholder/team

• Creates/manages the product backlog

• Events
- Sprint: short- xed length iteration (2-4 weeks) with potentially
shippable code at the end of the iteration

11 Teaching Assistant: Aanchal Narendran

fi
fi
 Software engineering Dr. Jayashree R
• One release may have any number of iterations

- Sprint planning meeting: determine items from product backlog that

will be worked on and delivered

• Kicks o the sprint

• De ne the scope of delivery and how to accomplish

• Sets a common goal for the team

• Attended by
- Product owner: prioritise backlog items and propose sprint goal
- Development team: determine how many backlog items can be
completed and how to do it

- Scrum master: facilitate the meeting, ensures agreement on

sprint goal and sprint scope

• Inputs to meeting
- Product backlog

- Capacity of the team

- Past performance of the team

• Activities
- Identify sprint goal

- Choose stories

- Plan for capacity

- Daily scrum meeting/standup meeting

• Discuss: what was done yesterday? What will be done today?
Obstacles?

• Update status/track on scrum board/burndown chart

- Sprint review

• Demonstrates story features

• Product owner evaluates against preset criteria

• Get feedback from client and stakeholders

12 Teaching Assistant: Aanchal Narendran

fi
ff
 Software engineering Dr. Jayashree R
• Ensure delivered increment meets business need

• Helps reprioritise product backlog and optimise release

- Sprint retrospective
• Optimises the process after each iteration

• Final team meeting to discuss past sprint and future scope

• Attended by the Scrum master

• Artifacts
- Split work into a list of small concrete deliverables; sort on priority
and e ort estimate

- Product backlog: project/product features

• New features, changes to existing, bug xes, infra set-up

• Features described in terms of user stories

• Scrum team estimates work associated with each story and ranks
them in order of importance

• Weighted-ranked features in the backlog result in a roadmap

• Features/stories planned for a sprint is the sprint backlog

• Alignment with agile manifesto

- Individual and interactions over processes and tools

• Cross functional teams, scrum meeting and sprint reviews

- Working software over comprehensive docs

• Periodic customer deliverable at the end of the sprint can be reviewed

and experienced

- Customer collaboration over contract negotiation

• Customer experience sprint outcomes and participate in sprint reviews

- Responding to change over following a plan

• User stories ensure requirement changes can be factored in

- Focus on simplicity

• Planning is short term focused and hence simple

13 Teaching Assistant: Aanchal Narendran

ff
fi
Software engineering Dr. Jayashree R
• Extreme agile programming (XP)
- Estimates, plans and delivers highest priority user stories in the form of
tested software in an iteration

- Working software at very frequent intervals

- Continuous feedback and test-driven

- Requirement change can happen at anytime

- Practices in XP
• Planning game: scope of next release

• Small releases: simple system is realised

• Communication: communicate requirements to the team; Small team

• Simple design: only for the user story

• Customer: onsite and continuously involved

• Feedback through: unit testing, customer-acceptance, team discussions

• Pair programming: two people work on an activity

• Refactoring: change/throw away obsolete problem

• Continuous integration: multiple times a day

• Collective code ownership: code can be modi ed by anyone

• Coding standards: ease of communication
• Metaphor: common vision on operation with common names to address
issues

• Sustainable pace: team works standard hours

- Usage:

• Requirements are unsure

• System is not too big
• Customer on site

• Lean Agile: similar to agile methodology but works faster with more
sustainable results

- Identify and eliminate activity not valued by customer

14 Teaching Assistant: Aanchal Narendran

fi
Software engineering Dr. Jayashree R
- Kaizen: continuous inspection to adapt and improve

- Boosts performance

- Amplify active learning

- Decide as late as possible

Component based software engineering

- CBSE: reuse based approach to de ne, implement or select of-the shelf

components and integrate/compose loosely coupled independent components
into systems

• Motivation: increase in complexity of system, need for quicker Turn Around

Time

- Reuse rather than re-implement to shorten development time

- Advantages and Disadvantages

Advantages Disadvantages

Black-Box component reduces complexity Trustworthiness of components

Reduced development time Component certi cation

Increased quality and productivity Emergent property prediction

Requirement trade o

- Essentials for successful CBSE

• Independent components that are completely speci ed by public interfaces

• Component standards that facilitate integration

• Middleware provides software support for integration

• Development process is geared towards CBSE

- Software component
• Implements functionality without regard to where the component is being
executed or the programming language

- Independent executable entity of one/more executable objects

- Component interface is published; all interactions through this interface

15 Teaching Assistant: Aanchal Narendran

fi
ff
fi
fi
Software engineering Dr. Jayashree R
- Explicit dependencies through “required” interfaces

• Identifying the software component

- Searching for a component

- Selection of the component

- If no ready component, compose component from existing

- Sequential composition and additive or may need some adapter or “glue”
to reconcile di erent component interfaces

- Validate the component

• Component Development Stages

- Forms of Component
• During development: UML

• Packaging: .zip

• Execution: code and data blocks

• Elements of component model
- Interfaces: how component can interact; de nes operation names,
parameters, exceptions (included in interface de nition)

- Usage: globally unique name and a handle associated with it

- Deployment: how it should be packaged for deployment

16 Teaching Assistant: Aanchal Narendran

ff
fi
fi
 Software engineering Dr. Jayashree R

Product lines

- Software product lines: engineering techniques for creating a portfolio of

similar software systems from a shared set of software assets

• Reuse is imperative

• Represent a family of manufactured product

• Product line architecture: captures commonality and variability of product

line components and compositions

• Advantages
- Create software for di erent products
- User variability to customise software to each product

- Key drivers for reuse

• Predictive software reuse

• Software artefacts created when reuse is predicted in one or more products

• Artefacts could be built as components or design patterns

- Engineering Framework

Requirements engineering

- Generics: rst step in any software intensive development lifecycle

• Di cult, error prone and costly

- Errors introduced may propagate and expensive to x

17 Teaching Assistant: Aanchal Narendran

ffi
fi
ff
fi
 Software engineering Dr. Jayashree R
• Critical for successful development of all downstream activities

- Requirement: property which must be exhibited by software developed/

adapted to solve a particular problem

• Specify externally visible behaviour of what and not how

• Can be individual or set of requirements

• Properties:
- Clear: precise and simple language

• Active present tense; constant terminology; avoid combining

- Concise: describe a single property with as few words as possible

- Consistent: no requirements should contradict each other

- Unambiguous: should only have one interpretation

- Feasible: realizable in speci ed time frame

- Traceable: backwards to stakeholder request and forwards to software

components

- Veri able: clear, testable criterion and cost-e ective process to check it has
been realised

- Prioritized
- Quanti able: aids in testing and verifying
- Feasibility study
• Done before beginning a project

• Short, low cost study to asses practicality of the project

• Activities
- Figure out Client/sponsor/user would have a stake in project

- Current solution to the problem?

- Target customers and future market space?

- Potential bene ts?

- Scope on a high-level

- High block level understanding of solution

18 Teaching Assistant: Aanchal Narendran

fi
fi
fi
fi
ff
Software engineering Dr. Jayashree R
- Considerations in tech
- Marketing strategy

- Financial projections

- Schedule and high level planning; budget requirements

- Issues, assumptions, risks and constraints

- Alternatives and their consideration

- Potential project organisation

- Requirements engineering process

• Requirements elicitation
- Work with all stakeholders to gather their needs, articulate the problem,
identify and negotiate con icts: establish clear scope and boundary for a
project

- Stakeholder has been given an opportunity to explain their problem and

needs

- Involves
• Understanding problem, domain, needs and constraints
• Identifying clear objectives
• Writing business objectives for the project

- Elicitation techniques

• Approach depends on

- Nature of system being developed

- Background and experience of stakeholders

• Active
- Ongoing interaction b/w stakeholders and users

- Interviews; facilitated meetings

19 Teaching Assistant: Aanchal Narendran

fl
 Software engineering Dr. Jayashree R
- Role-playing; prototyping

- Ethnography and scenarios

• Passive
- Infrequent interaction

- Use cases; business process analysis and modelling

- Work ows and questionnaires

- Checklist and documentation
• Requirements analysis
- Understand requirements from both product and process perspective

- Classify and organise requirements into coherent clusters

• Functional, non-functional and domain

- Functional: functionality or services the system should provide with
di erent inputs and expression on how the system should behave

• High-level statements

• Can be veri ed

• Indicated states what the system should not do

- Non-functional: constraints on service or functions o ered by the

system (timing, dev process, etc)

• Often applied to the system as a whole

• Specify the criteria that is used to judge the operation

- Domain: constraints on system from domain of the operation

• System and user

- User: statements in natural language + informal context diagrams
system/subsystem and their interconnections and operational
constraints

• Written for/by customers

- System: structured document; detailed desc of systems functions,

services and operational constraints.

- Model the requirements

20 Teaching Assistant: Aanchal Narendran

ff
fl
fi
ff
Software engineering Dr. Jayashree R
• Primary goals: provide an understanding system

- Analyse and validate requirements

- Communicate the requirements in terms of who, what and interpreting it
the same way

• Types of models
- Structural
• Static aspects of the system

• Entities in the system

• How are they related

- Behaviour models
• Dynamic aspects of the system

• How do entities respond to stimulus

- Analyse the requirements with sh bone diagram

- Recognise and resolve con icts (functionality vs time vs cost)

- Negotiate requirements

- Prioritise requirements (MoSCoW - Must have , Should have, Could have,

Wont have)

- Identify risks if any

- Decide on build or buy and re ne requirements

• Commercial O The Shelf

21 Teaching Assistant: Aanchal Narendran

ff
fl
fi
fi
 Software engineering Dr. Jayashree R
• Uni ed modelling language
- Specifying, visualising, constructing, and documenting artefacts of
complex software systems

- UML use case model + modelling systems: discuss dynamic behaviour of

system when it is running

• Gather requirements

• External and Internal in uences

- Important role in de ning perspectives

• Design
• Implementation
• Process
• Deployment

- UML has 13 types of diagrams split into 2 categories

• Static Diagrams: static structure of what is in the system

- Examples: Class, Component, Deployment, Composite Structure,

Object, Package

• Dynamic Diagrams: Shows what happens during execution

- What’s happening in the system: Activity, State Machine, Use Case

- Flow and Control of Data: Interaction

- Other Examples: Communication, Sequence and Timing

22 Teaching Assistant: Aanchal Narendran

fi
fi
fl
Software engineering Dr. Jayashree R
- Conceptual elements of UML
• Building Blocks: make up the UML

• Rules: dictates how building blocks can be put together

• Common Mechanisms: apply through out UML

• Things: abstractions in a model

- Four categories of Things

• Structural

• Behavioural

• Grouping

• Annotate

• Relations: ties together things or abstractions

- Four types of Relations

• Dependency

• Association

• Generalisation

• Realisation

• Diagrams: graphical representation where vertices indicate things and

arcs indicate relations

- Examples: Class, Object, Use Case, Sequence, Collaboration,

Statechart, Activity, Component, Deployment

• Using use case diagrams

- From users point of view, outline how the proposed system will
perform a task

23 Teaching Assistant: Aanchal Narendran

Software engineering Dr. Jayashree R
- Specifying desired behaviour of the system as sequences of action a
system is expected to perform to yield an observable result of value

- Visualise, specify, construct and document behaviour

• Developers, domain experts and end-user

- Use case has following elements

• Actor: someone interacting with the use case (system function)

• Requirements speci cation

- Documentation of set of requirements that is reviewed and approved by
the customer and provides direction for software construction activities

- Software requirements speci cation (SRS)

• Basis for customers and contractors/suppliers agreeing on what they will

and will not do;

• functional and non functional requirements

- Reasons for documentation

• Visibility

• Formalisation leads to better clarity

• User support
• Team communication
• Maintenance and evolution
- Characteristics of documentation
• Accurate and current
• Appropriate for audience

• Maintained online

• Simple but professional

- Functionality: what is the software supposed to do

- External interface: how does it interact with people, hardware and software

- Non functionality: quality criteria for functionality

• Performance: speed, response time, recovery time, etc

24 Teaching Assistant: Aanchal Narendran

fi
fi
 Software engineering Dr. Jayashree R
• Other attributes: availability, portability, correctness, maintainability

- Design constraints imposed

• Required standards in e ect

• Implementation language
• Policies for DataBase integrity
• Resource limit
• Security
• Operating environment
• Requirements validation
- Repairing requirements downstream can be expensive
- Validation and veri cation

• Validation: software requirements if implemented will solve the right

problem and satisfy user need

• Veri cation: wether requirements have been speci ed correctly

- Requirement reviews
• Consistency

• Completeness

• Veri ability

• Comprehensibility

• Traceability

• Adaptability

- Prototyping
• Facilitates user involvement and ensures users and engineers have same
interpretation

• Most bene cial in systems with many user interactions

- Model validation
• Model represents all essential functional requirements (Use case model)

25 Teaching Assistant: Aanchal Narendran

fi
fi
fi
fi
ff
fi
Software engineering Dr. Jayashree R
• Demonstrating each model is consistent ( ow diagrams)

• Fish bone analysis to validate if requirements addresses the reasons

for needing a solution to the problem

- Acceptance criteria
• See if any requirements match the acceptance criteria

• Requirements management
- Potential reasons for requirement change
• Better understanding of the problem
• Customer internalising
• Evolving environment and Technology
- Two facets
• Ensure requirements are addressed in all phases of the lifecycle

• Ensure changes in requirements are handled appropriately

- Requirements traceability matrix (RTM)

• Each phase progressively lls RTM

• Requirements traced along SDLC using the RTM

- Forward and backward tracing

- Requirements change management

• Change in requirements impact plans, work products, etc

• Uncontrolled changes can have huge, adverse impact (cost, schedule,

quality and expectation)

• Allow controlled changes

- Formal change management process
• Log the request for change and assign change request id

26 Teaching Assistant: Aanchal Narendran

fi
fl
Software engineering Dr. Jayashree R
- Log: who is requesting? Why is the request coming in? What is
being requested?

• Perform impact analysis on work products and items

• Estimate impact on scope, e ort and schedule

• Review impact with stakeholders

• Solicit formal approval

• Rework the work products/items

• Log the following

- When was it changed

- Who all made changes? Reviewed changes? Tested changes?

- Which release stream is it a part of?

27 Teaching Assistant: Aanchal Narendran

ff