Intro To SE & SDLC

I N T RO D U C T I O N TO
S O F T WA R E E N G I N E E R I N G
Subject : Software Engineering
Course: Bachelor of Computer Science &
Bachelor of Computer Engineering
(Ts.) SSS Shameem Software Engineering, MIU

I N T RO D U C T I O N
➢ All the systems are software controlled
➢ Economies of ALL developed nations are dependent on software used in various industry/sector.
➢ Software engineering is concerned with theories, methods and tools for professional software
development.
• Software is a Computer programs and associated documentation. Software products may be

developed for a particular customer or may be developed for a general market.
• Good software should deliver the required functionality and performance to the user and
should be maintainable, dependable and usable.
• Software engineering is an engineering discipline that is concerned with all aspects of software
production.

Fundamental software engineering activities;

• Software specification, software development, software validation and software evolution.
➢ System engineering is concerned with all aspects of computer-based systems development

including hardware, software and process engineering.
➢ Software engineering is part of this more general process.
• Computer science focuses on theory and fundamentals.

• Software engineering is concerned with the practicalities of developing and delivering useful
software.

Costs of software engineering;

• Roughly 60% of software costs are development costs,
• 40% are testing costs.
• For custom software, evolution costs often exceed development costs.
➢ All software projects have to be professionally managed and developed, and different
techniques are appropriate for different types of system.
• Ex., games should always be developed using a series of prototypes whereas safety critical
control systems require a complete and analyzable specification to be developed.
• Can’t be said that one method is better than another.

Key challenges facing software engineering;

• Coping with increasing diversity,
• demands for reduced delivery times and
• developing trustworthy software.
➢ The web has led to the availability of software services and the possibility of developing
highly distributed service-based systems.
➢ Web-based systems development has led to important advances in programming languages
and software reuse.

IMPORTANT
E S S E N T I A L AT T R I B U T E S O F G O O D S O F T WA R E
Acceptability
• Software must be acceptable to the type of users for which it is designed.
• It must be understandable, usable and compatible with other systems that user choses to use
Efficiency
• Software should not make wasteful use of system resources such as memory and processor
cycles.
• Efficiency therefore includes responsiveness, processing time, memory utilisation, etc.

E S S E N T I A L AT T R I B U T E S O F G O O D S O F T WA R E
Dependability and security

• Software dependability includes a range of characteristics including reliability, security and safety.
• Dependable software should not cause physical or economic damage in the event of system
failure.
• Malicious users should not be able to access or damage the system.
Maintainability
• Software should be written in such a way so that it can evolve to meet the changing needs of
customers.
• A critical attribute because software change is an unavoidable requirement of a changing business
environment.

S O F T WA R E C O S T S
• Software costs often dominate computer system costs.
o The costs of software on a PC are often greater than the hardware cost.
• Software costs more to maintain than it does to develop.
o For systems with a long life, maintenance costs may be several times development costs.
• Software engineering is concerned with cost-effective software development.

S O F T WA R E P RO D U C T S
Generic products
• Stand-alone systems that are marketed and sold to any customer who wishes to buy them.
• Examples – PC software such as graphics programs, project management tools; software for
specific markets such as CRM, HRM systems for office environment.
Customized products
• Software that is commissioned by a specific customer to meet their own needs.
• Examples – factory production control systems, traffic monitoring systems etc.

P R O D U C T S P E C I F I C AT I O N
Generic products
• The specification of what the software should do is owned by the software developer and
decisions on software change are made by the developer.
Customized products
• The specification of what the software should do is owned by the customer for the
software and they make decisions on software changes that are required.

S O F T WA R E E N G I N E E R I N G
• Software engineering is an engineering discipline that is concerned with all aspects of software
production from the early stages of system specification through to maintaining the system after
it has gone into use.
• Engineering discipline
o Using appropriate theories and methods to solve problems bearing in mind organizational and financial
constraints.
• All aspects of software production
o Not just technical process of development.
o Also project management and the development of tools, methods etc. to support software production.

I M P O RTA N C E O F S O F T WA R E E N G I N E E R I N G
• More and more, individuals and society rely on advanced software systems.
• Need to be able to produce reliable and trustworthy systems economically and quickly.
• It is usually cheaper, in the long run, to use software engineering methods and techniques for
software systems rather than just write the programs as if it was a personal programming
project.
• For most types of system, the majority of costs are the costs of changing the software after it
has gone into use.

IMPORTANT
A P P L I C AT I O N T Y P E S
Stand-alone applications
• These are application systems that run on a local computer, such as a PC.
• They include all necessary functionality and do not need to be connected to a network.
Interactive transaction-based applications

• Applications that execute on a remote computer and are accessed by users from their own
PCs or terminals.
• These include web applications such as e-commerce applications.
Embedded control systems

• These are software control systems that control and manage hardware devices.
• Numerically, there are probably more embedded systems than any other type of system.

A P P L I C AT I O N T Y P E S ( C O N T. )
Batch processing systems
• These are business systems that are designed to process data in large batches.
• They process large numbers of individual inputs to create corresponding outputs.
Entertainment systems
• These are systems that are primarily for personal use and which are intended to entertain the
user.
Systems for modelling and simulation

• These are systems that are developed by scientists and engineers to model physical processes
or situations, which include many, separate, interacting objects.

A P P L I C AT I O N T Y P E S ( C O N T. )
Data collection systems

• These are systems that collect data from their environment using a set of sensors and send that
data to other systems for processing.
Systems of systems
• These are systems that are composed of a number of other software systems.

I N T RO D U C T I O N TO
S O F T WA R E D E V E LO P M E N T L I F E C YC L E
(SDLC)
(Ts.) SSS Shameem

S O F T WA R E D E V E LO P M E N T
• Software Requirements Specification
• Software Design
• Implementation (Coding & Module Testing)
• Integration, Testing, & Maintenance
Each stage will require respective Software Quality Assurance (SQA).

(Ts.) SSS Shameem
(Ts.) SSS Shameem
S O F T WA R E D E V E LO P M E N T
Software Development Components End product
• Software requirements • SRS, IRS
• Preliminary Design • SDD, PQT/FAT/SAT Plans & Proc.’s, ICD, IDD
• Detailed Design • PDL, User Manuals
• Code • Code, UT Plan & Proc.’s
• Testing • UT Results
• Unit Test • VDD
• Software integration • PQT Report
• Software Component Test • FAT & SAT Reports
• Software System Test • ECP’s leading to updates
• Maintenance and Support

D E L I V E R A B L E S O F T H E S D LC
Approved Feasibility Abort Project
Preliminary Study
Investigation Goto next phase
Problem Goto Previous phase
System Specifications
Analysis
System
Design Specifications
Design
Coded and
System
Tested System
Development
Begin building
System System converted
new system Implementation Users trained
System
Maintenance
Operational System
Documentation completed

Systems development life cycle (SDLC) –
a structured step-by-step approach for developing information systems.
(Ts.) SSS Shameem

IMPORTANT

S E V E N P H A S E S I N T H E S D LC
Plan Analysis Design Develop Test Implement Maintain
Involves determining a solid plan for developing the information system.
Most important activities involved:
• Identify and select the system for development
• Set project scope
• Develop the project plan including tasks, resources, and timeframes.

Identify and select the system for development
• Key question: “What systems are required to support the strategic goals of
your organization?”
• generate proposals to build new information systems when they are having a
difficult time performing their jobs.
• Companies cannot develop all proposed IS, so they look into the critical
success factors.

Once the system to be developed in defined, then project needs to be scoped.
Set project scope - clearly defines the high-level system requirements.
• birds-eye-view of the project.
• Project scope document - a written definition of the project scope, and is

usually no longer than a paragraph.

• Developing a project plan is the final activity of planning phase.
Project plan - defines the what, when, and who questions of system
development including all activities to be performed, the individuals, or
resources, who will perform the activities, and the time required to
complete each activity.

The project plan should include:
• Project milestones - represent key dates for which you need a certain group of
activities performed.
• Project manager - an individual who is an expert in project planning and

management, defines and develops the project plan and tracks the plan to ensure
all key project milestones are completed on time.

The analysis phase involves
• End users, &
• IT specialists
working together
• To understand, &
• Document
the business requirements for the system.

• Gather Business requirements - the detailed set of knowledge worker

requests that the system must meet in order to be successful.
• Key activity = Gathering clearly defined business requirements.
• Gathering business requirements = investigation.

A useful way to gather system requirements is:
1. Joint application development (JAD) - knowledge workers and IT specialists meet,

sometimes for several days, to define or review the business requirements for the system.
2. Requirements definition document – prioritizes the business requirements and places

them in a formal comprehensive document.
3. Sign-off - the knowledge workers’ actual signatures indicating they approve all of the
business requirements.

Primary goal of design phase
• To Build the technical architecture required to support the

system.
This includes
• Design of the technical architecture
• Design system models.

Technical architecture –
• Defines hardware, software, and telecommunications equipment required to run system
The final architecture must meet the needs in terms of
• Time
• Cost
• Technical feasibility
• Flexibility
It is important to ensure that the final architecture meet

• Current system needs
• Future system needs
Modeling - the activity of drawing a graphical representation of a design.
• Reports
• Programs
• databases

Different types of modeling activities performed during the design stage
• Graphical user interface (GUI)

• The interface to an information system.
• the ability to model the information system screens for an entire system.
• Entity relationship diagram
• Data flow diagram
• Flowcharting

Take all detailed design documents from the design phase and transform them
into an actual system.
Activities during this phase include In other words

• Coding programs Build the technical architecture.
Build the database and programs.
• Creating databases
• Deploying the telecommunications equipment
• Installing hardware and software

Testing phase Perform the testing of the entire system.
• Verifies that the system works and meets all of the business requirements
defined in the analysis phase.
Test conditions - detailed steps; system must perform along with expected results of
each step.
Testing is critical
• Must have test plans
• Write the test conditions

Implementation phase
• Bringing the system into life by placing it in the organization
• Distribute the system to all of the knowledge workers, and they begin using the
system to perform their everyday jobs.
Create User documentation: Highlights how to use the system.
• Perform training to the employees to use the system

• Online training - runs over the Internet or Intranet.
• Workshop training - held in a classroom environment and lead by an instructor.

Maintenance phase
• It is the final phase of the system development effort
• Monitor and support the new system to ensure it continues to meet
the business goals.
Once the system is in place, support need to be provided
• Build a help desk to support the system users.

• Provide an environment to support system changes.

T H E S O F T WA R E P RO C E S S
• A structured set of activities required to develop a software system.

• Many different software processes but all involve:
▪ Specification – defining what the system should do;
▪ Design and implementation – defining the organization of the system and

implementing the system;
▪ Validation – checking that it does what the customer wants;
▪ Evolution – changing the system in response to changing customer needs.

• A software process model is an abstract representation of a process.
• It presents a description of a process from some particular perspective.

S O F T WA R E D E V E LO P M E N T AC T I V I T I E S
Requirements Collection Establish customer’s needs
Analysis Model and specify the requirements (“what”)
Design Model and specify a solution (“how”)
Implementation Construct a solution in software
Testing Validate the solution against the requirements

Repair defects and adapt the solution to new
Maintenance
requirements
These are ongoing activities, not sequential phases!

S O F T WA R E P RO C E S S D E S C R I P T I O N S
• When we describe and discuss processes, we usually talk about the activities in these processes
such as specifying a data model, designing a user interface, etc. and the ordering of these
activities.
• Process descriptions may also include:
▪ Products, which are the outcomes of a process activity;
▪ Roles, which reflect the responsibilities of the people involved in the process;
▪ Pre- and post-conditions, which are statements that are true before and after a process
activity has been passed or a product produced.

P L A N - D R I V E N A N D AG I L E P RO C E S S E S
• Plan-driven processes are processes where all of the process activities are planned in
advance and progress is measured against this plan.
• In agile processes, planning is incremental and it is easier to change the process to reflect
changing customer requirements.
• In practice, most practical processes include elements of both plan-driven and agile approaches.
• There are no right or wrong software processes.

S D L C - A D V A N TA G E S
• Focus on tradeoffs
• Focus on goals
• Controls: milestones, checklist, accountability
• Tools, models, CASE
• Hierarchical decomposition
• Designed for user & manager involvement

W H Y S Y S T E M S FA I L
IMPORTANT
Five primary reasons why systems fail include:
1. Unclear or missing requirements
2. Skipping SDLC phases
3. Failure to manage project scope
4. Failure to manage project plan
5. Changing technology

W H Y S Y S T E M S FA I L
• Gathering inaccurate requirements?
• System must not allow students to add classes
• System must allow students to add classes
• Missing Requirement?
• Forgetting to include into the system the calculation of a student grade point average
• The project manager must track the status of each activity and adjust the project plan if a activity is
added or taking longer than expected.
• What could happen in a project to this effect is
• Scope creep - occurs when the scope of the project increases.
• Feature creep - occurs when extra features added that were not part of initial requirements.

S D L C - R E A S O N S F O R FA I L U R E . . 1
• Scope too broad or too narrow
• Lack of needed skills
• Incomplete specifications
• No control/no framework
• Lack of management/user involvement
• Too time-consuming

S D L C - R E A S O N S F O R FA I L U R E . . 2
• Business requirements drive the entire system. If they are not accurate or complete, there is no way the
system will be successful.
• Technology changes so fast that it’s almost impossible to deliver an information system without feeling
the pain of changing technology.
• Project plan is the road map you follow during the development of the system.
• Developing the initial project plan is the easy.
• Managing, revising, and updating the project plan is the hard part.
• First thing individuals tend to do when a project falls behind schedule is to start skipping phases in SDLC.
• Skipping any of the phases is sure to lead to further complications, and system failure.

L I F E C YC L E M O D E L
• A software lifecycle model is a description of the sequence of activities carried
out in an SE project, and the relative order of these activities.
• provides a fixed generic framework that can be tailored to a specific project.
• Project specific parameters will include:
• Size, (person-years)
• Budget,
• Duration.
project plan = lifecycle model + project parameters

• Hundreds of different lifecycle models to choose from, but many are
minor variations on a smaller number of basic models.
• Scrum
• Waterfall • Cleanroom
• Prototype • RAD
model
• DSDM
• Incremental
• RUP
• Iterative
• XP
• Spiral
• Lean
• Agile
• Dual Vee Model
• V-Model
• TDD
• FDD

IMPORTANT
CODE-AND-FIX
• Starts with an informal general product idea, and just develops code until a
product is ready (or money or time runs out).
• Work is in random order.
• Corresponds with no planning

CODE-AND-FIX
A D V A N TA G E S
• No administrative overhead
• Signs of progress (code) early.
• Low expertise, anyone can use it!
• Useful for small “proof of concept” projects, e.g. as part of risk reduction.

CODE-AND-FIX
D I S A D VA N TA G E S
Dangerous!
• No visibility/control
• No resource planning
• No deadlines
• Mistakes hard to detect/correct
Impossible for large projects, communication breakdown, chaos.

IMPORTANT
W AT E R FA L L
• Sequential design process
• Progress is seen as flowing steadily downwards (like waterfall) through SDLC

W AT E R FA L L
• Introduced by Royce 1970.
• Classic lifecycle model
• Widely known, understood and commonly used.
• Considered as the common sense approach.
• Jump to next phase only if the prior one is completed

A D V A N TA G E S
• Reinforces good habits: define-before- design, design-before-code
• Identifies deliverables and milestones
• Detailed early analysis cause huge advantages at later phases
• If a bug found earlier, it is much cheaper (and more effective) to fix than bugs found
in a later phase
• Requirement set before design starts
• Points to importance of documentation
• Disciplined and well-structured approach
• Effective for stable software projects
• Easy to plan from project management point of view

D I S A D V A N TA G E S
• Idealised, doesn’t match reality well.
• Client does not explicitly know what he or she wants, at the beginning
• Client does not explicitly know what is possible/practical to have
• Need to finish every phase fully
• Software is delivered late in project, delays discovery of serious errors.
• Difficult to integrate risk management
• Difficult and expensive to make changes to documents, swimming upstream.
• Significant administrative overhead, costly for small teams and projects.
• Long projects, difficult to keep the plan
• Designers may not know in advance how complex a feature’s implementation

IMPORTANT
P ROTOT Y P I N G
• Creating prototypes of software applications i.e. incomplete versions of the software program
being developed
• A prototype typically simulates only a few aspects of, and may be completely different from, the
final product.
• Key idea: Customers are non-technical and usually don’t know what they want/can have.
• Rapid prototyping emphasises requirements analysis and validation, also called:
✓ customer oriented development,
✓ evolutionary prototyping

R A P I D P ROTOT Y P E WO R K F LOW
Requirements Capture
Iterate
Quick Design
Build Prototype
Customer Evaluation of
Prototype
Engineer Final
Product
A D V A N TA G E S
• Reduces risk of incorrect user requirements
• Good where requirements are changing/uncommitted
• Regular visible progress aids management
• Supports early product marketing

• An unstable/badly implemented prototype often becomes the final product.
• Requires extensive customer collaboration
• Costs customers money
• Needs committed customers
• Difficult to finish if customer withdraws
• May be too customer specific, no broad market
• Difficult to know how long project will last
• Easy to fall back into code-and-fix without proper requirements analysis, design,
customer evaluation and feedback.

IMPORTANT
I T E R AT I V E D E V E L O P M E N T
• In practice, development is always iterative, and all activities progress in parallel.
• Plan to iterate your analysis, design and implementation.
• You won’t get it right the first time, so integrate, validate and test as frequently as possible
iterate: perform or utter repeatedly.

Requirements Testing based on requirements
Collection
Maintenance through iteration Testing
Analysis Testing throughout implementation

Validation through prototyping
Implementation
Design
Design through refactoring

IMPORTANT
I N C R E M E N TA L B U I L D M O D E L
Model is designed, implemented and tested incrementally
• A little more is added each time
• Finished when satisfies all the requirements.
• Combines the elements of the waterfall model with the iterative philosophy of prototyping.

I T E R AT I V E A N D I N C R E M E N TA L D E V E LO P M E N T
Iterative and incremental development is any combination of both iterative design or iterative
method and incremental build model for development.

I N C R E M E N TA L V S . I T E R AT I V E

A B I T D I F F E R E N T U N D E R S TA N D I N G

SPIRAL MODEL
• Combining elements of design and prototyping-in-stages
• Combines the features of the prototyping and the waterfall model
• Spiral model is intended for large, expensive and complicated projects
• Advantages of top-down and bottom-up concepts

SPIRAL MODEL
Since end-user requirements are hard to obtain/define, it is natural to develop software
in an experimental way: e.g.
1. Build some software
2. See if it meets customer requirements
3. If NO, then goto 1 else stop.
This loop approach gives rise to structured iterative lifecycle models.
In 1988 Boehm developed Spiral model as an iterative model which includes risk analysis and
risk management.
Key idea: on each iteration identify and solve the sub-problems with the highest risk.

Cumulative cost
Determine objectives,
alternatives & constraints Evaluate alternatives,
Identify & resolve risks
Prototypes Operational
Review & Start P1 P2 P3 Prototype
commitment Requirements Concept
Design, Detailed design
plan Of Operation Validation
Development & Verification
plan Requirements
validation Coding
Integration &
Test plan Unit & Integration
Plan next phase Testing Develop & verify
End Acceptance
Testing next-level product
SPIRAL MODEL
Each cycle follows a waterfall model by:
• Determining objectives
• Specifying constraints
• Generating alternatives
• Identifying risks
• Resolving risks
• Developing next-level product
• Planning next cycle

A D V A N TA G E S
• Realism: the model accurately reflects the iterative nature of software development
on projects with unclear requirements
• Flexible: incoporates the advantages of the waterfal and rapid prototyping methods
• Comprehensive model decreases risk
• Good project visibility.

• Needs technical expertise in risk analysis to really work
• Model is poorly understood by non-technical management, hence not so widely used
• Complicated model, needs competent professional management. High administrative overhead.

AGILE
• Modern model in 21st centrury.
• Group of software development methods
• Based on iterative and incremental development
• focus on process adaptability and customer satisfaction by rapid delivery of working software product.
• break the product into small incremental builds.

• These builds are provided in iterations.
• Each iteration typically lasts from about one to three weeks.
• Every iteration involves cross functional teams working simultaneously on various areas; Planning,
Requirements Analysis, Design, Coding, and Testing, etc
• At the end of iteration, a working product is displayed to the customer and important stakeholders

AGILE
• Most important phrases
o self-organizing, cross-functional teams
o adaptive planning,
o evolutionary development and delivery,
o a time-boxed iterative approach,
o rapid and flexible response to change.
• A conceptual framework
• Customer Interaction is backbone of this Agile methodology.
• open communication with minimum documentation are common.

AGILE
• Agile model believes that every project needs to be handled differently and the existing
methods need to be tailored to best suit the project requirements.
• In Agile, the tasks are divided to time boxes (small time frames) to deliver specific features
for a release.
• Iterative approach is taken and working software build is delivered after each iteration.
• Each build is incremental in terms of features; the final build holds all the features required by
the customer.

AGILE
• Traditional SDLC models (waterfall) are based on predictive approach.
• Usually work with detailed planning and have a complete forecast of the exact tasks and
features to be delivered in the next few months or during the product life cycle.
• entirely depend on the requirement analysis and planning done in the beginning of cycle.
• Any changes to be done, goes through strict change control management and prioritization.
• Agile is based on the adaptive software development methods.
• no detailed planning; and clarity on future tasks only on what features need to be developed.
• feature driven development, and team adapts to changing product requirements dynamically.
• product is tested very frequently through release iterations, minimizing risk of any major
failures in future.
A G I L E : A D V A N TA G E S
• Is a very realistic approach to software development.
• Promotes teamwork and cross training.
• Functionality can be developed rapidly and demonstrated.
• Resource requirements are minimum. • Minimal rules, documentation easily employed.

• Suitable for fixed or changing requirements • Little or no planning required.
• Delivers early partial working solutions. • Easy to manage.
• Good model for environments that change steadily. • Gives flexibility to developers.

A G I L E : D I S A D V A N TA G E S
• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and extensibility.
• An overall plan, an agile leader and agile PM practice is must without which it will not work.
• Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet
the deadlines.
• Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong
direction.
• There is a very high individual dependency, since there is minimum documentation generated.
• Transfer of technology to new team members may be quite challenging due to lack of documentation.

AGILE

V- M O D E L
• An extension of waterfall model.
• Show relationships between development phases and test phases
• Time and project completeness vs. level of abstraction

V- M O D E L

V E R I F I C AT I O N V S . V A L I D AT I O N
IMPORTANT

V- M O D E L

V- S H A P E D S T E P S
• Project and Requirements Planning – allocate • Production, operation and maintenance –

resources provide for enhancement and corrections
• Product Requirements and Specification • System and acceptance testing – check the
Analysis – complete specification of the entire software system in its environment
software system • Integration and Testing – check that modules
• Architecture or High-Level Design – defines interconnect correctly
how software functions fulfill the design • Unit testing – check that each module acts as
• Detailed Design – develop algorithms for each expected
architectural component • Coding – transform algorithms into software

V- S H A P E D S T R E N G T H S
• Emphasize planning for verification and validation of the product in early stages of
product development
• Each deliverable must be testable
• Project management can track progress by milestones
• Easy to use

V- S H A P E D W E A K N E S S E S
• Does not easily handle concurrent events
• Does not handle iterations or phases
• Does not easily handle dynamic changes in requirements
• Does not contain risk analysis activities

W H E N TO U S E T H E V- S H A P E D M O D E L
• Excellent choice for systems requiring high reliability – hospital patient control applications
• All requirements are known up-front
• When it can be modified to handle changing requirements beyond analysis phase
• Solution and technology are known

W MODEL

Selecting/changing to suitable lifecycle model can improve and/or tradeoff:
• Development speed (time to market)

• Product quality
• Project visibility
• Administrative overhead
• Risk exposure
• Customer relations, etc, etc.

S / W T E S T I N G L I F E C YC L E ( S T LC )
• When to Start Testing?
• When to Stop Testing?
• Who does Testing?

IMPORTANT
S / W T E S T I N G L I F E C YC L E ( S T LC )
1 3
2
4

S U M M A RY
• SDLC
• STLC

Intro To SE & SDLC

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Intro To SE & SDLC

Uploaded by

Copyright:

Available Formats

I N T RO D U C T I O N TO

Subject : Software Engineering

Course: Bachelor of Computer Science &

Bachelor of Computer Engineering

(Ts.) SSS Shameem Software Engineering, MIU

• Software is a Computer programs and associated documentation. Software products may be

(Ts.) SSS Shameem Software Engineering, MIU

Fundamental software engineering activities;

➢ System engineering is concerned with all aspects of computer-based systems development

• Computer science focuses on theory and fundamentals.

(Ts.) SSS Shameem Software Engineering, MIU

Costs of software engineering;

(Ts.) SSS Shameem Software Engineering, MIU

Key challenges facing software engineering;

(Ts.) SSS Shameem Software Engineering, MIU

(Ts.) SSS Shameem Software Engineering, MIU

Dependability and security

(Ts.) SSS Shameem Software Engineering, MIU

• Software costs often dominate computer system costs.

• Software costs more to maintain than it does to develop.

• Software engineering is concerned with cost-effective software development.

(Ts.) SSS Shameem Software Engineering, MIU

(Ts.) SSS Shameem Software Engineering, MIU

(Ts.) SSS Shameem Software Engineering, MIU

(Ts.) SSS Shameem Software Engineering, MIU

(Ts.) SSS Shameem Software Engineering, MIU

Interactive transaction-based applications

Embedded control systems

(Ts.) SSS Shameem Software Engineering, MIU

Systems for modelling and simulation

(Ts.) SSS Shameem Software Engineering, MIU

Data collection systems

(Ts.) SSS Shameem Software Engineering, MIU

(Ts.) SSS Shameem

• Software Requirements Specification

• Implementation (Coding & Module Testing)

• Integration, Testing, & Maintenance

Each stage will require respective Software Quality Assurance (SQA).

(Ts.) SSS Shameem Software Engineering, MIU

(Ts.) SSS Shameem Software Engineering, MIU

(Ts.) SSS Shameem Software Engineering, MIU

(Ts.) SSS Shameem

(Ts.) SSS Shameem Software Engineering, MIU

Plan Analysis Design Develop Test Implement Maintain

Involves determining a solid plan for developing the information system.

Most important activities involved:

• Identify and select the system for development

• Set project scope

• Develop the project plan including tasks, resources, and timeframes.

(Ts.) SSS Shameem Software Engineering, MIU

Plan Analysis Design Develop Test Implement Maintain

Identify and select the system for development

(Ts.) SSS Shameem Software Engineering, MIU

Plan Analysis Design Develop Test Implement Maintain

Once the system to be developed in defined, then project needs to be scoped.

Set project scope - clearly defines the high-level system requirements.

• birds-eye-view of the project.

• Project scope document - a written definition of the project scope, and is

(Ts.) SSS Shameem Software Engineering, MIU

Plan Analysis Design Develop Test Implement Maintain

• Developing a project plan is the final activity of planning phase.

(Ts.) SSS Shameem Software Engineering, MIU

Plan Analysis Design Develop Test Implement Maintain