Scribd
Upload
13 views

Software Engineering Notes

The document discusses various process models for software development including waterfall, agile, incremental, spiral, reuse-oriented engineering, extreme programming (XP), scrum, and plan-based approaches. It also covers topics like requirements engineering, use case modeling, system modeling using UML diagrams, and architecture design.

Uploaded by

kamrul
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
13 views

Software Engineering Notes

The document discusses various process models for software development including waterfall, agile, incremental, spiral, reuse-oriented engineering, extreme programming (XP), scrum, and plan-based approaches. It also covers topics like requirements engineering, use case modeling, system modeling using UML diagrams, and architecture design.

Uploaded by

kamrul
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

Process Model

 For safety critical system we need waterfall model, because safety-critical


system requires a lot of up-front analysis before implementation. This
model does not include customer feedback. Also it is rigid to changes. Its
needs well defined requirements at the early stage of development. It
Minimizes risk of late-stage changes disrupting operations.
 Agile software development includes weekly or monthly incremental
delivery, includes customer feedback at each delivery. Flexible and less
expansive.
o Individual and interactions over processes and tools
o Working software over comprehensive documentation
o Customer collaboration over contract negotiation
o Responding to change over following a plan



 Agile VS incremental: Incremental models plan further ahead, while agile
focuses on short bursts. Incremental models have larger, less frequent
iterations compared to agile's short sprints. If core maintenance features
are well-defined, Incremental might be efficient.

 When to use spiral: the spiral model for projects with high levels of
uncertainty and risk that require a risk-driven approach to development.

 Reuse-oriented software engineering - This approach is based on the


existence of a significant number of reusable components. The system
development process focuses on integrating these components into a
system rather than developing them from scratch

 XP: Agile++, pair programming, Test-driven development, Extreme


programming expresses user requirements as stories, with each story
written on a card.
 Plan-Based Approaches: waterfall, spiral, incremental. Agile is not plan-
based.

 Scrum: Fixed-length sprints or time-boxed iteration (1-4 weeks), Emphasizes


roles and ceremonies (product owner, scrum master, not manager).
Small/mid size project. Daily meeting.

RE
 System Requirements can only be implemented after the user requirements
are understood and finalized. User Requirements describe the system
functions and features from the perspective of a user. These are usually
abstract. System requirements provide a more detailed explanation of the
procedure.

 various requirement engineering concepts:

1. User Requirements:
 Example: "As a customer, I want to search for products by category and filter by
price range to find the perfect item quickly and easily."
2. System Requirements:
 Example: "The system shall provide a search function that allows users to search for
products by category and filter results by price range. The search results shall be
displayed in a user-friendly and paginated format, with at least 10 products per
page."
3. Functional Requirements:
 Example: "The search function shall search product titles, descriptions, and
specifications for keywords entered by the user."
 "The filter function shall allow users to refine search results by selecting a minimum
and maximum price range from a drop-down menu."
4. Non-functional Requirements (it can be two types: non func syst req):
 Example: "The search function shall return results within 2 seconds after the user
submits their query."
 "The system shall be accessible to users with disabilities and comply with relevant
accessibility standards."
 "The system shall be secure and protect user data from unauthorized access.".
 Structure approach to RE:
 Function
 Description
 Input
 Source
 Outputs
 Destination
 Action : Zero state...
 Requires
 Precondition
 Post condition: target found/gas issued
 Side-effects

 The following diagram shows a change process that may be used to maintain
consistency between the requirements document and the system.

USE CASE
 Structure of Use case in table:
 Actors
 Inputs
 Outputs
 Normal operation
 Exception
Modelling
 Scope creep: define boundaries, functionalities
 Social and organizational concerns mean the position of a system boundary
may be determined by non-technical factors
 Activity diagram (structural perspective, overall flow of control)): activity
(rounded rect., actions or tasks), action edge, decision. Start , stop  . Use
black line for merging or multiple outing. Example:

 Sequence diagram(interaction perspective, interactions between objects):


Objects: Participants in the interaction, typically represented as vertical
lifelines.
Messages: Arrows passing between objects, denoting communication and data
flow
Time sequence: Ordered from top to bottom, illustrating the chronological
order of interactions.

 Model an object classes means define class with variables and methods
 ATM cash withdraw actors: User, atm-system, card controller, bank, account.

State Diagram
 Washing machine, idle used used more than once. Start from idle, start and
stop state.
Model Driven Approach (MDA) fo SE
 Uses UML
 Need tools
 suitable for long-lifetime systems
 relies on code-generation which may be less efficient than hand written

Architecture
 Need to design architecture before RE because:
 Provide a means of structuring the R, cost estimation
 To understand functional and nonfunctional requirements
 In agile, refactoring architecture is expensive because most system
components will need to be modified.
 you need to model the architecture to identify subsystems and associate
the requirements with these subsystems.
 Performance wants few large component for less comm. But security needs
layered architecture, more component for validation. Conflict


You might also like