Introduction The key challenges facing software engineering? Analysis and Design Ñ Software architechture document on: 2-3.

Key objective of software engineering: cost-effective soft- Heterogeneity, delivery and trust. (SAD) RUP Workflows
ware development. Issues of professional responsibility Implementation and Unit Testing Ñ Source code and Business modeling: The business processes are modeled
Software Confidentiality, Competence, Intellectual property rights, test cases using business use cases
Computer programs and associated documentation. Computer misuse Integration and System Testing Ñ Test results Requirements: Requirements specification, use-case mo-
Software can be created by developing new programs, Software Process Traditional Methods Operation and Maintenance Ñ User manual document del
configuring generic software systems, reusing existing Software Development Approaches and Training document Analysis and Design: Software architecture and design
software. Plan-driven (SW-CMM, document-based, heavy process) Problems are created, Different software views (use-case view, de-
Software Engineering Agile (XP, tacit knowledge, light process) Inflexible partitioning into distinct stages sign view, process view, implementation view, deployment
Software engineering is an engineering discipline that is Key Definitions Only appropriate when the requirements well-understood view)
concerned with theories, methods, tools for professional Agile method one which fully adopts the four value pro- Mostly used for large systems engineering projects Implementation: Software components are implemented
software development Process iteration Testing: Includes testing activities performed to verify
positions and twelve principles in the Agile Manifesto.
Cost effective (within budget), On time, High quality, Plan – (per Webster) a method for achieving an end Divided into many iterations and validate the product against the requirements
Satisfying customer’s needs Iteration can be applied to any of the generic process Deployment: Activities to release and deploy the product
(a process plan); an orderly arrangement of parts of an
What is a software process? models and help users to use the product successfully
overall design (a product plan)
Specification - what the system should do and its deve- Configuration and Change Management (SCM): Mana-
Plan-driven a description for disciplined methods (order Two (related) approaches: Incremental delivery / deve-
lopment constraints lopment and Spiral development ges changes to the software product
is often defined in plans)
Development - production of the software system Incremental development Project Management: Manages software development
The Agile Manifesto
Validation - checking that the software is what the cu- Development and delivery is broken down into incre- Environment: Prepares and ensures software tools, pro-
Individuals and interactions over processes and tools
stomer wants ments. cesses, and hardware for the development team
Working software over comprehensive documentation
Evolution - changing the software in response to chan- Requirements are prioritized. RUP Good Practices
Customer collaboration over contract negotiation
ging demands. Advantages: System functionality is available earlier, Ear- Develop software iteratively, Manage requirements, Use
Responding to change over following a plan
What is a software process model? ly increments act as a prototype to help elicit require- component-based architectures, Visually model software,
Popular Plan-driven and Agile Methods Verify software quality, Control changes to software, Use
A simplified representation of a software process, presen- Plan-driven ments, Highest priority requirements tend to receive most
Agile methods testing, Lower risk of overall project failure. tools, Use-case driven development, Modeling and UML.
ted from a specific perspective. methods Extreme
Examples of process perspectives are: Workflow per- Waterfall Spiral Development CMMI-Capability Maturity Model Integration
Programming
spective - sequence of activities, Data-flow perspective Spiral Each spiral represents a phase in the process; No fixed CMMI is a framework for software and systems process
Scrum
- information flow, Role/action perspective - who does Rational Unified phases such as specification or design; Risks are assessed maturity
Crystal
what Process Feature Driven and resolved throughout the process. CMMI Model Components
Generic process models: Waterfall, Iterative develop- Personal Software Process Development (FDD) Spiral Model Sectors Process Area: A cluster of related practices in an area
ment, Component-based software engineering CMMI Objective setting: Specific objectives for the phase are that satisfy a set of goals
Costs of software engineering Plan-driven Methods identified Goal: Generic goal, Specific goal
Roughly 60% of costs are development costs, 40% are Structured approaches to software development that are Practice: Generic practice, Specific practice
Risk assessment and reduction: Risks are assessed, Mit-
testing costs. guided or driven by plans. Work product: Any artifact produced by a process
igation activities are planned and taken
Disciplined methods, traditional methods, defined in Sub-practice: Providing guidance for Practice
What are software engineering methods? Development and validation: Develop and validate sys-
plans and relied on documentation.
Structured approaches to software development, inclu- tem Project Management
ding system models, notations, rules, design advice and Strengths Planning: Review previous spiral, Plan for next spiral
High assurance, suitable for safety-critical software sys-
Software Project Management
process guidance. RUP Goal: on time, within budget, in accordance with the re-
Model descriptions: Descriptions of graphical models tems; Suitable for large software systems; Documentation
Normally described from 3 perspectives: Dynamic per- quirements, high quality, satisfied customers
which should be produced available for training new staff; Making sure everyone to
spective: shows phases over time; Static perspective: Responsibility: project manager, program manager, team
work in certain ways through clear processes.
Rules: Constraints applied to system models shows process activities; Practical perspective: suggests lead, test manager,...
Recommendations: Advice on good design practice Weakness good practice. Software projects have some differences from common
Process guidance: What activities to follow. Documentation overhead, Outdated and useless docu-
RUP Phases projects: intangible, flexible, depends on human factors.
ments, Inflexible to changes, Obstruct innovations, En-
What is CASE? Inception: Establish the business case for the system Project Manager Skills Requirements
gineers don’t like documentation
Computer-Aided Software Engineering: Software sys- Elaboration: Develop an understanding of the problem Technical project management, Leadership, Strategic and
tems that are intended to provide automated support for Waterfall Model domain and the system architecture. business management.
software process activities. Requirements definition Ñ Analysis and Design Ñ Imple-
Construction: System design, programming and testing Project Planning
mentation and Unit Testing Ñ Integration and System
Upper-CASE: Tools to support the early process activi- Transition: Deploy the system in its operating environ- Defining goals, what, who, when (and how) to do. Con-
Testing Ñ Operation and Maintenance.
ties of requirements and design ment tinuous activity. Dependent on processes followed.
Two stages cannot be performed at the same time; Each
Lower-CASE: Tools to support later activities such as
stage has to be completed before doing the next stage; RUP Iteration Inputs for Planning
programming, debugging and testing.
A stage is completed if a set of criteria is met; Going Considered a waterfall cycle; Each iteration has entry and Project proposal, Organizational policies, Standard pro-
What are the attributes of good software back to the previous stage is possible. exit criteria or check points; cesses, Historical data, information from previous projects
Maintainability, Dependability, Efficiency and Acceptabi- Typical number of iterations per phase: Inception: 1-2 Tools and Techniques for Planning
A set of standard outcomes of each stage
lity. iterations, Elaboration: 1-3, Construction: 2-3, Transiti- Expert judgement, Brainstorming, Checklists, Interviews,
Requirements definition Ñ Requirements documents
CS300 - Semester I NHHMinh
Meetings Burndown chart: showing the progress Goals and requirements
Main activities to form SDP Activities: Release planning, Sprint planning, Daily Goal: A general intention of the user such as ease of use
Estimate overall project effort, cost, and staff; Plan pha- Scrum, Sprint review. User requirements
ses, iterations; Define and customize processes to use; Kanban Should describe functional and non-functional require-
Assign roles and responsibilities to staff; Plan training Kanban board – a board used to visualize work items ments in a way understandable by system users. User
needs; Identify and assess risks. Kanban card – a card represents one work item. Cards requirements are often defined using natural language,
Project scheduling are moved from left to right. Cards flow from one stage tables and diagrams
Goal: assigning right people to right tasks at right time to another in the system Requirements Engineering
Challenges: Estimating each task is difficult; Adding peo- Four principles: Start with what you are doing now; Agree Requirements engineering (RE) processes
ple to a late project makes it later; Unexpected things to pursue incremental, evolutionary change; Respect cur- RE process is a set of activities performed to create soft-
always happen rent roles, responsibilities and job-titles; Encourage acts ware requirements
Risk Management of leadership at all levels. Feasibility studies
Goal: minimize effects of risks on project Benefits: Simple and flexible planning, Shortened cycle Feasibility studies decide whether or not the proposed
Risk Types: Technology; People; Organisational; Requi- time, Few bottlenecks. system is worthwhile
rements; Estimation. Where Agile Methods Work Best? Requirements elicitation and analysis
Risk Management Strategies Small teams (2 – 20 people); Short iterations (1 – 2 Involves technical staff working with customers to find
Organisational financial problems: Prepare a briefing do- weeks); Collocated teams – not recommended for distri- out the application domain, the services that the system
cument for senior management showing how the project buted teams; Non safety-critical systems should provide, the system’s operational constraints.
is making a very important contribution to the goals of Strength and Weakness Use Case Diagrams
the business. Strength: Suitable for dynamic, chaotic environments; Main elements: Actors, Use cases, Relationships.
Recruitment problems: Alert customer of potential diffi- Supportive of emergent requirements, rapid change; Avoi- Actor: An actor represents an external person, process,
culties and the possibility of delays, investigate buying-in ding documentation overhead; Empowering/encouraging or anything that interacts with the system
components. people
Use Cases: describes a set of sequences of actions per-
Staff illness: Reorganise team so that there is more over- Weakness: Requiring high-capable, self-motivated peo- formed by an actor to produce observable results value
lap of work and people therefore understand each other’s ple; Difficult in safety-critical systems; Problem in large to the actor
jobs. projects
Types of Use Case Relationships
Defective components: Replace potentially defective Software Requirements
Association: actors and use cases
components with bought-in components of known relia- Requirements
Generalization: Between general use cases and more spe-
bility. Descriptions of the system services and constraints. Re- cific ones
Requirements changes: Derive traceability information quirements specify what services a system provides and
Include: Between use cases
to assess requirements change impact, maximise infor- how the services are executed
Extend: Between use cases
mation hiding in the design. Requirements engineering: establishing services, cons-
Organisational restructuring: Prepare a briefing docu- traints. Requirements validation
ment for senior management showing how the project is Types of requirement Validate that the requirements reflect what the customer
making a very important contribution to the goals of the User requirements: Statements in natural language of wants: Validity, Verifiability, Consistency, Completeness,
business. Realism.
system’s services and their operational constraints, User Techniques: Requirements reviews, Prototyping, Test-
Database performance: Investigate the possibility of bu- point of view
ying a higher performance database. case generation
System requirements: A structured document detailing
Underestimated development time: Investigate buying system’s functions, services and operational constraints; Requiments management
in components, investigate use of a program generator Define what should be implemented; Technical point of Process of managing changing requirements during the
Agile Methods project
view(designer, implementer, tester)
Main steps: Change request, Change analysis and
Extreme Programming Method Functional and non-functional requirements costing, Change implementation
Philosophy: Take known good practices and push them Functional: State how the system should react to particu-
to extremes lar inputs and how the system should behave in particular
The 12 Practices: The Planning Game, Small Releases, situations.
Metaphor, Simple Design, Testing, Refactoring, Pair Pro- Non-functional requirements: State Constraints on ser-
gramming, Collective Ownership, Continuous Integration, vices or functions offered by the system
40-hour Week, On-site Customer, Coding Standards. Domain requirements: come from the application do-
Scrum main of the system; reflect characteristics of that domain
Concepts Requirements completeness and consistency
Daily Scrum: a short daily meeting Complete: They should include descriptions of all facili-
Sprint: a development cycle (30 days) ties required
Backlog: Product backlog (list of product requirements), Consistent: There should be no conflicts or contradicti-
Sprint backlog (list of requirements allocated to the ons in the descriptions of the system facilities
sprint), Impediments backlog (list of issues).
Page - 2