Software technology 5. Design, implementation BSc Course Dr. Katalin Balla
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Software technology5. Design, implementation
BSc CourseDr. Katalin Balla
Contents� Design
� Definitions� The process� Software design principles and key issues in software design� Architectural styles and design patterns; architecture decisions� UI design� Design elements from CMMI and Automotive SPICE
� Implementation � Using coding standards� Checking code quality
� Estimation in software design� Design and implementation in the agile environment
10/8/2017 Balla K. 2
What is software Design? � The process during which:
� The requirements are used as starting point to a deeper understanding of the system and its elements
� Formalization of this understanding from different point of view, usually:
� Functionality� Functions, function groups , features…
� Data� Communication, interfaces among the elements� Formalization is done using different design models
� The requirements are grouped / converted to � Functionalities� Software structure
10/8/2017 Balla K. 3
Design in the SWEBOK� Design is defined as both “the process of defining the architecture,
components, interfaces, and other characteristics of a system or component” and “the result of [that] process” [1].
� Viewed as a process, software design is the software engineering life cycle activity in which software requirements are analyzed in order to produce a description of the software’s internal structure that will serve as the basis for its construction.
� A software design (the result) describes the software architecture—that is, how software is decomposed and organized into components—and the interfaces between those components. It should also describe the components at a level of detail that enables their construction. � [1] ISO/IEC/IEEE., 24765:2010 Systems and Software Engineering—Vocabulary,
ISO/IEC/IEEE, 2010.� From: SWEBOK , http://swebokwiki.org/Chapter_2:_Software_Design
10/8/2017 Balla K. 4
Design� During design a global, coherent view of the entire
system must be achieved!� Design is a step different from coding! Design is at a
higher level of abstraction than coding. � The level of detail used in design depends on many
elements. Different models use different concepts, but usually we have: � Software architectural design (sometimes called high-level
design): develops top-level structure and organization of the software and identifies the various components.
� Software detailed design: specifies each component in sufficient detail to facilitate its construction.
10/8/2017 Balla K. 5
Design
� Also, design elements named : �Conceptual / high level design�Detailed design
� The design gives basically 2 types of view on the system�Static view – dynamic view
Balla K. 610/8/2017
Design� Are there models usable only for design? (…and not usable
for eg. Requirements specification…) � No. Generally, a model can be used in more life cycle phases, with
different purposes. However, there are some „best practices” about which model in which phase is best to use
� Remember the UML diagrams from the first lectures! It was pointed out which diagram in which phase is best to use. But can be used in more points!
� Why do we need more models (structural, functional, use case, data etc.) ? � Different models capture different elements of a system; all together give a
broader view.
� Tools can help in checking consistency between different models.
10/8/2017 Balla K. 7
10/8/2017 Balla K. 8
How do we identify elements for the design? � Example: identifying the elements of a system in OO development
� Integration of the 3 models (OMT)
Class
Attributes
Methods
Dynamic model -> class
Functional model -> data warehouse, actor object, data flow
Dynamic model -> state variables, event parameters
Functional model -> data flow, data warehouse
Dynamic model -> actions, activities, events
Functional model -> processes
10/8/2017 Balla K. 9
Design in the software development lifecycle
Design in the systemdevelopment lifecycle
10/8/2017 Balla K. 10
From: Automotive SPICE , PAM, v3
Design in the software development lifecycle
10/8/2017 Balla K. 11
Software Design Principles� Key notions that provide the basis for many
different software design approaches and concepts.
� Single Responsibility Principle (SRP), Open/Closed Principle (OCP), Law of Demeter (LoD) etc.
� Already discussed in previous lectures, and to be studie d incoming years! (OO concepts- UML2)
Balla K. 1210/8/2017
Key issues in software design� Some are quality concerns that all software must
address—for example, performance, security, reliability, usability, etc. �Consider these aspects in design phase!
� Another important issue is how to decompose, organize, and package software components. Must be well / wisely done!
� Sometimes software’s behavior that is not in the application domain must be also considered during design � Eg. The system will be part of an already working system,
environment characteristics need to be considered etc . 10/8/2017 Balla K. 13
Software Structure and Architecture
� A software architecture is "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. � During the mid-1990s, however, software architecture
started to emerge as a broader discipline that involved the study of software structures and architectures in a more generic way.
10/8/2017 Balla K. 14
Architectural styles� An architectural style is “a specialization of element and
relation types, together with a set of constraints on how they can be used” .
� An architectural style can thus be seen as providing the software’s high-level organization.
� Various authors have identified a number of major architectural styles, for example: � General structures (for example, layers, pipes and filters, blackboard)� Distributed systems (for example, client-server, three-tiers, broker)� Interactive systems (for example, Model-View-Controller,
Presentation-Abstraction-Control)� Others (for example, batch, interpreters, process control, rule-based).
10/8/2017 Balla K. 15
Design patterns� A pattern is “a common solution to a common problem in
a given context” . While architectural styles can be viewed as patterns describing the high-level organization of software, other design patterns can be used to describe details at a lower level.
� These lower level design patterns include the following: � Creational patterns (for example, builder, factory, prototype,
singleton)� Structural patterns (for example, adapter, bridge, composite,
decorator, façade, flyweight, proxy)� Behavioral patterns (for example, command, interpreter, iterator,
mediator, memento, observer, state, strategy, template, visitor).
10/8/2017 Balla K. 16
Architecture Design Decisions
� Architectural design is a creative process. � During the design process, software designers have to
make a number of fundamental decisions that profoundly affect the software and the development process.� It is useful to think of the architectural design process from a
decision-making perspective rather than from an activity perspective.
� During design, impact on competing quality attributes, as well as user requirements are basis for the decisions. One must strive to achieve balance!
10/8/2017 Balla K. 17
Architecture Design Decisions
Balla K. 1810/8/2017
Sommerville - https://www.slideshare.net/software-engineering-book/ch6-architectural-design
Importance of reuse in design
� Families of Programs and Frameworks� One approach to providing for reuse of software designs and
components is to design families of programs, also known as software product lines.
� This can be done by identifying the commonalities among members of such families and by designing reusable and customizable components to account for the variability among family members.
� In object-oriented (OO) programming, a key related notion is that of a framework: a partially completed software system that can be extended by appropriately instantiating specific extensions (such as plug-ins).
10/8/2017 Balla K. 19
UI design� General User Interface Design Principles
� Learnability. The software should be easy to learn so that the user can rapidly start working with the software.
� User familiarity. The interface should use terms and concepts drawn from the experiences of the people who will use the software.
� Consistency. The interface should be consistent so that comparable operations are activated in the same way.
� Minimal surprise. The behavior of software should not surprise users.
� Recoverability. The interface should provide mechanisms allowing users to recover from errors.
� User guidance. The interface should give meaningful feedback when errors occur and provide context-related help to users.
� User diversity. The interface should provide appropriate interaction mechanisms for diverse types of users and for users with different capabilities (blind, poor eyesight, deaf, colorblind, etc.).
10/8/2017 Balla K. 20
Design in CMMI
� There is no single Process Area named „Design”
� Design is connected to�Requirements Development (RD, on ML3)�Technical Solution (TS, on ML3)
Balla K. 2110/8/2017
Requirements development� The purpose of Requirements Development (RD) is to elicit,
analyze, and establish customer, product, and product component requirements.
� SG 1 Develop Customer Requirements � SP 1.1 Elicit Needs � SP 1.2 Transform Stakeholder Needs into Customer Requirements
� SG 2 Develop Product Requirements � SP 2.1 Establish Product and Product Component Requirements � SP 2.2 Allocate Product Component Requirements � SP 2.3 Identify Interface Requirements
� SG 3 Analyze and Validate Requirements � SP 3.1 Establish Operational Concepts and Scenarios � SP 3.2 Establish a Definition of Required Functionality and Quality Attributes � SP 3.3 Analyze Requirements � SP 3.4 Analyze Requirements to Achieve Balance � SP 3.5 Validate Requirements
10/8/2017 Balla K. 22
Technical solution� Evaluating and selecting solutions (sometimes
referred to as “design approaches,” “design concepts,” or “preliminary designs”) that potentially satisfy an appropriate set of allocated functional and quality attribute requirements
� Developing detailed designs for the selected solutions (detailed in the context of containing all the information needed to manufacture, code, or otherwise implement the design as a product or product component)
� Implementing the designs as a product or product component
10/8/2017 Balla K. 23
Technical solution
� SG 1 Select Product Component Solutions � SP 1.1 Develop Alternative Solutions and Selection Criteria � SP 1.2 Select Product Component Solutions
� SG 2 Develop the Design � SP 2.1 Design the Product or Product Component � SP 2.2 Establish a Technical Data Package � SP 2.3 Design Interfaces Using Criteria � SP 2.4 Perform Make, Buy, or Reuse Analyses
� SG 3 Implement the Product Design � SP 3.1 Implement the Design � SP 3.2 Develop Product Support Documentation
10/8/2017 Balla K. 24
Design in Automotive SPICE� Extremely important with embedded systems!� Architecture element:
�Result of the decomposition of the architecture on system and software level: � The system is decomposed into elements of the
system architecture across appropriate hierarchical levels.
� The software is decomposed into elements of the software architecture across appropriate hierarchical levels down to the software components (the lowest level elements of the software architecture).
10/8/2017 Balla K. 25
Documenting the design
� Design documentation�High level design�Low level design�Models, descriptions, rationale, decisions�Version control needed, for design documents
as well!� Eg: during testing a design error is discovered and
corrected, but it is not documented in the design documentation
Balla K. 2610/8/2017
Design documentation� Product or product component designs should provide the
appropriate content not only for implementation, but also for other phases of the product lifecycle such as modification, reprocurement, maintenance, sustainment, and installation.
� The design documentation provides a reference to support mutual understanding of the design by relevant stakeholders and supports future changes to the design both during development and in subsequent phases of the product lifecycle.
� A complete design description is documented in a technical data package that includes a full range of features and parameters including form, fit, function, interface, manufacturing process characteristics, and other parameters. � Based on CMMI –DEV v1.3
10/8/2017 Balla K. 27
Architectural design. Example
Balla K. 2810/8/2017
Detailed design. Examples.
� 1016-2009 - IEEE Standard for Information Technology--Systems Design--Software Design Descriptions
� SDD templates available�Overview of the system�Architectural design�Data design�Component design�Human interface design
Balla K. 2910/8/2017
When is a design „good”?
� (…example…)� Standardised, understandable � Consistent with itself� Non-redundant…
� Quality attributes for design can be formulated.
Balla K. 3010/8/2017
Software Design Quality Analysis and Evaluation
� Various attributes contribute to the quality of a software design, including various “-ilities” (maintainability, portability, testability, usability) and “-nesses” (correctness, robustness).
� There is an interesting distinction between quality attributes discernible at runtime (for example, performance, security, availability, functionality, usability), those not discernible at runtime (for example, modifiability, portability, reusability, testability), and those related to the architecture’s intrinsic qualities (for example, conceptual integrity, correctness, completeness)
10/8/2017 Balla K. 31
Quality Analysis and Evaluation Techniques
� Various tools and techniques can help in analyzing and evaluating software design quality. See a more detailed description in Testing and Quality lectures!�Software design reviews: informal and formalized
techniques �Static analysis: formal or semiformal static
(nonexecutable) analysis that can be used to evaluate a design (for example, fault-tree analysis or automated cross-checking).
�Simulation and prototyping: dynamic techniques to evaluate a design (for example, performance simulation or feasibility prototypes).
10/8/2017 Balla K. 32
Design – a profession
� Doing design requires specific skills! It is usually done by designers. �Designers can come from
� User / business environment ( for high level design)
� IT specialists (for detailed design)� Best if there is a team of designers!
10/8/2017 Balla K. 33
Design – a profession� A good designer considers different alternatives and evaluates
them for eg:� Cost of development, manufacturing, procurement, maintenance, and support � Achievement of key quality attribute requirements, such as product timeliness, safety,
reliability, and maintainability � Complexity of the product component and product related lifecycle processes � Robustness to product operating and use conditions, operating modes, environments, and
variations in product related lifecycle processes � Product expansion and growth � Technology limitations � Sensitivity to construction methods and materials � Risk � Evolution of requirements and technology � Disposal� Capabilities and limitations of end users and operators � Characteristics of COTS products
Balla K. 3410/8/2017
As a future designer you must know …� There is no unique set of design principles or
elements, accepted by everyone everywhere, however, there are some principles that must be considered
� Experience will help you as a designer!�Be open-minded and patient until you gather the
experience needed to be a good designer!�Learn patterns, look to existing design documents
and try to recognize / reuse them in a new situation!
Balla K. 3510/8/2017
Implementation issues
� Not only programming, but also: �Reuse �Configuration management �Host-target development
Balla K. 36 10/8/2017
Implementation
� Coding, technical documentation� Coding standards!
�Structure, comments, naming of the variables…�Avoid common mistakes
� Organizational set of process assets- with good / bad examples of piece of code
� The importance of best practices in programming� Reuse of previous experience
Balla K. 3710/8/2017
Documenting theimplementation� Code + other technical documentation � Any decisions, experiences…� Be careful with code changes!� There must be a bidirectional traceability
between Requirements – Design- Code-Test case!
� Configuration management and version control!
Balla K. 3810/8/2017
Estimation in software engineeringactivities
� Estimation helps in understanding what is going to happen� Historical data needed!� Done usually for:
� Effort – to be discussed in PM lecture� Cost - – to be discussed in PM lecture� Size
� Further estimations can be derived for:� Number of modules, interfaces� Time needed to complete each task� Number of bugs injected , removed and remaining in each phase� Defect density� Etc.
Balla K. 3910/8/2017
Estimation connected to design� Estimating the size of the system� Not easy!� Some methods exist – but experience
needed!� Next, we present 2 estimation techniques
usable in design and coding:�PROBE method (used in PSP)�Function points
Balla K. 4010/8/2017
10/8/2017 Balla K. 41
PROBE Method - I
� The PSP uses the PROBE method to estimate and plan projects.
� PROBE stands for PROxy Based Estimating.
� PROBE uses proxies (=substitutes) to estimate program size and development time.
� A good proxy will help you to make accurate estimates.
10/8/2017 Balla K. 42
PROBE Method - IIConceptual
designStart
Identify and size the proxiesNumber ofitems
PartType
Relativesize
Reusecategories
Estimate other element sizes
Estimateprogram size
Calculateprediction interval
Size estimateand range
Estimateresources
Calculateprediction interval
Resource estimateand range
10/8/2017 Balla K. 43
PROBE Method - III
� The first estimating step is to make a conceptual design.� relate the requirements to the product� define the product elements that will produce the
desired functions
� For most projects, the conceptual design can be produced relatively quickly.
� For the PSP programs, try to limit your conceptual design time to 10-20 minutes
10/8/2017 Balla K. 44
PROBE Method - IV
� Selecting an appropriate proxy:�Related to development effort�Automatically countable proxy content�Easily visualized at the project’s beginning�Customizable to the needs of the using
organization�Sensitive to implementation variations
10/8/2017 Balla K. 45
PROBE Method - V
� Possible proxies:�Objects �Function-point�Screens�Files�Scripts�Document chapters
� used in PSP
10/8/2017 Balla K. 46
PROBE Method - VI
� The first step was producing a conceptual design
� The second step is identifying the objects:�Determine object type and relative size� Identify reused categories
� Reuse library� New reused objects
10/8/2017 Balla K. 47
PROBE Method - VII
� Determine object type and relative size� Example C++ class size ranges
10/8/2017 Balla K. 48
PROBE Method - VIII
� The third step is calculating estimated object LOC� Including added, modified, deleted, base, and reused code� When modifying an existing program, base code is the size
of the unmodified existing program.� When modifying programs, include their unmodified size in
base code and not in reuse.� While base code is a form of reuse, the PSP only counts
unmodified code from the reuse library as reused.
� Tool:� https://www.processdash.com/static/help/frame.html?UsingProbeTool=
10/8/2017 Balla K. 49
A method to measure and estimate software product complexity: function point counting
� Method development goal: to permit comparing the efficiency of software development done with different technologies
� Albrecht’s goals with function point counting:� Software size should have a consequent metric� Should be independent of the technology applied � Its use should be easy� The results should meaningful for the end user also
� Later: the finding that the method can be well applied for estimation based on the specification
(Source: Charles Symons: Come back Function Point Analysis (Modernised)- all is Forgiven!Software Measurement Services10th May 2001, FESMA Conference )
10/8/2017 Balla K. 50
How function point counting can be used?
10/8/2017 Balla K. 51
Function point counting
� … should be simple� … should relate to the company data
coming from other measurement methods � … should be „international”� … should relate to other software metrics
10/8/2017 Balla K. 52
Albrecht’s function point model
� 1970
Certain characteristics are monitored, their presence / importancerated from 0-5
10/8/2017 Balla K. 53
Function point counting methods� IFPUG
☺The most used, lot of experience, case studies
☺Large organisational background (training, consulting, certificate…)
☺Well applicable in data processing systems �Not applicable for real time systems�Applicable only for „application type”
software�Structure of the method and the used
weights /priorities is questionable
10/8/2017 Balla K. 54
Function point counting methods� MkII method(http://www.uksma.co.uk/public/mkIIr131.pdf)
� Steps of counting (measurement):
� Defining the view, goal and type of measurement
� Define what will be counted / measured
� Defining the borders of counting
� What is subject of counting and what is not
� Identifying logical transactions
� Logical transactions are the lowest level processes in the system, that arestill subject of counting
� Defining and grouping entity types
� Existence of an entity-relationship model helps: it can serve as a basisfor definition and grouping
10/8/2017 Balla K. 55
MkII method� Steps of counting (measurement) (continued):
� Counting the input data elements, the referenced entity types and the output data elements
� Determine for all logical transaction: input data types (Ni), referenced entity types (Ne) and output data types (No).
� Determining the functional size
� Is done using the following formula:
� FPI = Wi x ΣNi + We x ΣNe + Wo x ΣNo, where
� FPI = Function Point Index
� Wi, We and Wo are weight averages of Ni, Ne and No, with the values: Wi = 0.58, We = 1.66 és Wo = 0.26.
� Steps of counting (measurement) (continued):
� Determining the effort needed by the project
� Determine total expenditure / effort and time elapsed
� Determining productivity and other indicators
� E.g.: Productivity = FPI / project expenditure
10/8/2017 Balla K. 56
Function point counting methods� MkII
☺ Developed and largely used for management systems, well usable in estimations
☺ IFPUG enhancement, for systems containing larger amount of data
☺ Consistent with structured analysis methods ☺ Applicable in early stages of the life cycle ☺ Large organisational background, raining, certificate…(
but less large than IFPUG’s)� Has been used for real time systems, but needs re-
definition for such cases� Usable only for application – type software
10/8/2017 Balla K. 57
Cosmic method� https://cosmic-sizing.org/publications/early-
estimating-using-cosmic-ffp/
� Based on a simple model of software functionality
10/8/2017 Balla K. 58
Cosmic method
� Sizing conventions�Size of one functional process
� Arithmetic sum of data movement number (input, output, read, write)
� Minimal size: 2� Maximal size: no upper limit
�The size of a software item is the sum of the size of its functional processes
10/8/2017 Balla K. 59
Cosmic method
☺ Simple and unambiguous ☺ Can be applied to any type of software (MIS and real
time)☺ Can be applied to any component of multi-layer
architecture☺ Used by: IBM, in estimating in OO development
projects, telecom, aeronautic – industry...� Less experience, few case studies� Less detailed counting guidelines
10/8/2017 Balla K. 60
Cosmic, exampleSimple database enquiryRequirement: based on a user ID provided, the system
should be able to display all information related to that userOne Entry for User ID
One Read to find the user-record
One Exit to display user data
One Exit for all possible errors and confirmation messages
Total size: 4 Cfsu(comparison:IFPUG: Simple EQ of 3 UFP’s, plus allowance for fi lesMkII FPA: 1 x input DET, 1 x ER, assume 10 output DET’s = 5.1 FP)
10/8/2017 Balla K. 61
Cosmic, example 1� Conventions: � In the case of error and confirmation messages:
� We do not count a Read (the messages are „within the software”)
� We count one single Exit for all error and confirmation messages
� The entire functionality associated to the headings of the fields displayed are associated to the Exit data movement
Function points- standardized
� COSMIC: ISO/IEC 19761:2011 Software engineering. A functional size measurement method.
� FiSMA: ISO/IEC 29881:2010 Information technology – Systems and software engineering – FiSMA 1.1 functional size measurement method.
� IFPUG: ISO/IEC 20926:2009 Software and systems engineering –Software measurement – IFPUG functional size measurement method.
� Mark-II: ISO/IEC 20968:2002 Software engineering – Ml II Function Point Analysis – Counting Practices Manual
� NESMA: ISO/IEC 24570:2005 Software engineering – NESMA function size measurement method version 2.1 – Definitions and counting guidelines for the application of Function Point Analysis
Balla K. 6210/8/2017
Design in the agile environment
� Focus : on early solution exploration. � Solutions can be defined in terms of
� functions, feature sets, releases, or any other components that facilitate product development.
� When someone other than the team will be working on the product in the future, release information, maintenance logs, and other data are typically included with the installed product.
� To support future product updates, rationale (for trade-offs, interfaces, and purchased parts) is captured so that why the product exists can be better understood.
10/8/2017 Balla K. 63
Estimation in Agile
Balla K. 6410/8/2017
http://www.codingthearchitecture.com/2010/07/13/estimating_a_software_system.html
� The goal is the same as in traditional estimation
� The techniques might differ
Agile design practices
10/8/2017 Balla K. 65
Agile design
10/8/2017 Balla K. 66
https://www.onshape.com/cad-blog/agile-product-design-requires-a-new-generation-of-cad
Agile design elements
Balla K. 672017.10.08.
http://www.agilemodeling.com/
Agile design
� User story definition is part of the design activities (we saw them in requirements, as well)� In consultation with the customer or product
owner, the team divides up the work to be done into functional increments called "user stories.„
Balla K. 6810/8/2017
Agile design
� User Story Definition�For the next release
� 1 iteration ~ 1-2 weeks (sprint)� 2-5 iteration = 1 release ~ 1-2 month� 1 project ~ 3-6 months
�Requirements are frozen! (???)
10/8/2017 Balla K. 69
“Walking on water and developing software from a spe cification are easy if both are frozen.” Edward Berard
3. release2. release1. release
6. sprint5. sprint4. sprint3. sprint2. sprint1. sprint
Agile design
� User Story Definition�For the next sprint
� Only small modification are allowed� Ideas become clearer� Implementation level is reached� Collaboration with the user
� NB.: design and (project) planning go mostly hand-in-hand!!!!
10/8/2017 Balla K. 70
3. release2. release1. release
6. sprint5. sprint4. sprint3. sprint2. sprint1. sprint
Agile design
� User Story Definition�At the end of Sprint
� Production-Ready functions� Presented by the development team
10/8/2017 Balla K. 71
3. release2. release1. release
6. sprint5. sprint4. sprint3. sprint2. sprint1. sprint
Agile designElements
� User story
� List
� Estimations
� Burndown chart
� Team velocity
10/8/2017 Balla K. 72
User Story List
Identification 7SPRegistration 10SPlogout 2SPUser access 15SPUser search 7SPPrinting the data sheet 5SP
Time
SP
Ready
https://www.agilealliance.org/glossary/
At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity.Knowing velocity, the team can compute (or revise) an estimate of how long the project will take to complete, based on the estimates associated with remaining user stories and assuming that velocity over the remaining iterations will remain approximately the same. This is generally an accurate prediction, even though rarely a precise one.
Agilis design � User Story Definition
� „Requirement” – Not the best word� Together with Customer � Just In Time
� Physical vs. Virtual� There will be many.� Good to store electronically � Physical storage also usable
2017.10.08. Balla K. 73
Agile design
� User Story Mapping
10/8/2017 Balla K. 74
Time
Agile design
� User Story Mapping
10/8/2017 Balla K. 75
Time
Login LogoutManage
Ideas
Browse
Ideas
Agile design
� User Story Mapping
10/8/2017 Balla K. 76
Time
Login LogoutManage
Ideas
Browse
IdeasRelease 1
Agile design
� User Story Mapping
10/8/2017 Balla K. 77
Time
Login LogoutManage
Ideas
Browse
IdeasMinimal
Feedback Vote Message
Advanced
Release 1
Release 2
Release 3
…
BiometricAdvanced
SearchReporting
Agile design
� User Story Mapping� Result:
� Clear lifecycle picture � Clear(er) picture about the product� Further details were obtained
�The team sees� What will be the next release?� Features must be decomposed� Estimation� Prioritization
10/8/2017 Balla K. 78
Agile design� User Story Mapping
10/8/2017 Balla K. 79
2. release
3. iter2. iter
Agile design � A burn-down chart
�Project management and technical planning!
10/8/2017 Balla K. 80
Time
SP
1. iteration
1. release
Minimal Special functions
Agile design
� A burn-down chart
10/8/2017 Balla K. 81
SP New
requirement
Agile design
� A burn-down chart
10/8/2017 Balla K. 82
SP New
requirement
Agile design and planning
� There are many further alternatives for burn up/down-charts
� Matter of detail, but parts must be consistent
�We need a realistic plan!�Don’t expect miracles!�Ready when…
� Definiton Of Done� Analyised, implemented, tested, etc.…
10/8/2017 Balla K. 83
10/8/2017 Balla K. 84
The acronym INVEST stands for a set of criteria used to assess the quality of a user story . If the story fails to meet one of these criteria, the team may want to reword it.https://www.agilealliance.org
Agile design
Agile design� Definition of Done:
� The definition of done is an agreed upon list of the activities deemed necessary to get a product increment, usually represented by a user story, to a done state by the end of a sprint.
� The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a product increment "often a user story" is considered "done". Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint's velocity.
Balla K. 8510/8/2017
Agile design
� It can be seen that „software design”(a technical, engineering activity) and „project planning” (a managerial activity) sometimes overlap is the agile environment!
Balla K. 8610/8/2017
Agile designer
� User Experience, User Experience, User Experience!
� User in the center:�UX (User Experience) design – vs. UI
design.� UX values are „agile” � Pl.: Incremental, scratch first…
10/8/2017 Balla K. 87
Agile designer
8810/8/2017 Balla K.
Agile designer
8910/8/2017 Balla K.
Agile business analyst
� Agile business analyst�Helps recording User Stories�Helps in developing details�Just In Time – Important!
10/8/2017 Balla K. 90
Agile business analyst
Balla K. 9110/8/2017
http://masteringbusinessanalysis.com/mba045-the-agile-ba-myths-and-misconceptions/
Agile development
techniques:
Extreme programming
10/8/2017 Balla K. 92
Extreme Programming
� Extreme Programming (XP), originally introduced by Kent Beck, is an Agile approach to software developmentdescribed by certain values, principles, and development practices. �XP embraces five values to guide
development: communication, simplicity, feedback, courage, and respect.
Balla K. 9310/8/2017
Extreme Programming
� XP describes a set of principles as additional guidelines: �humanity, economics, mutual benefit, self-
similarity, improvement, diversity, reflection, flow, opportunity, redundancy, failure, quality, baby steps, and accepted responsibility.
Balla K. 9410/8/2017
Extreme Programming
� XP describes thirteen primary practices: � sit together, whole team, informative
workspace, energized work, pair programming, stories, weekly cycle, quarterly cycle, slack, ten-minute build, continuous integration, test first programming, and incremental design.
Balla K. 9510/8/2017
Agile development techniques
� Pair Programming� Pair programming consists of two
programmers sharing a single workstation (one screen, keyboard and mouse among the pair).
Balla K. 9610/8/2017
Agile development techniques
� Refactoring� Refactoring consists of improving the
internal structure of an existing program's source code, while preserving its external behavior.
Balla K. 9710/8/2017
Agile development techniques� Test Driven Develpment (TDD)� TDD is generally used in extreme
programming and agile development� See Lecture 7 (testing) and Lecture 2 (life cycle
models)
�The programmers write the tests first�The tests will be unsuccessful first�Gradually writes the code to the tests�The tests are supplemented with newer elements
Balla K. 9810/8/2017
Agile developer� Able to take technical
decision� Develops many-many tests!!!� Implements user stories� Has a quality-centric way of
thinking� Continuous refactoring,
development � One member of the team!!!
10/8/2017 Balla K. 99
http://www.developer.com/design/cartoon-of-the-week-are-you-an-agile-developer.html
Agile developer
10/8/2017 Balla K. 100
What we talked about…
� Design� Definitions. � The process� Software design principles and key issues in software design� Architectural styles and design patterns; architecture decisions� UI design� Design elements from CMMI and Automotive SPICE
� Implementation � Using coding standards� Checking code quality
� Design and implementation in the agile environment
10/8/2017 Balla K. 101
Related Documents
