1. Practice 2: Manage Requirements
You can generate discussion with the students concerning how they get requirements and how they manage them now.
Students who want to know in detail how to manage requirements should take the Requirements Management with use-cases course.
Develop Iteratively
Use
Component Architectures
Manage
Requirements
Verify
Quality
Model
Visually
Control Changes
A report by Standish Group cites forty percent of software projects fail.
This failure is attributed to:
poor requirements management; ((eliciting) capturing, (documenting) modeling,
verification; prototyping; agreeing w/customer on how changes will be handled, ...)
incorrect definition of requirements from the start of the project; and (feedback,
verification…)
poor requirements management throughout the development lifecycle.
(handling Change!!!) (Source: Chaos Report,
Module 1 - Best Practices of Software Engineering

2. Practice 2: Manage Requirements
Elicit, organize, and document required functionality and constraints
Evaluate changes and determine their impact
Track and document tradeoffs and decisions
Getting comprehensive system
requirements is a continuous process!
Obtaining a complete, exhaustive set of requirements prior to development is impossible!
Requirements are dynamic --
Expect them to change during software development
Change cannot be stopped, but it can be managed!!
Module 1 - Best Practices of Software Engineering

3. Definitions: Requirements and Their Management
A requirement is a condition or capability to which the system must conform
Requirements management is a systematic approach to
Eliciting, organizing, and documenting the requirements of the system, and
Establishing and maintaining agreement between the customer/user and the project team on the changing requirements of the system
Requirements specify ‘what’ the system must do - not how!
Requirements Management will be successful only if it allows for uncertainty early in development
Requirements Management must ensure requirements coverage over time.
It’s a good idea to have some examples of requirements to make this less abstract. Include functional requirements such as would be included in a use-case model. Also include design constraints, performance, legal, availability, etc. For an ATM machine, a functional requirement might be “withdraw cash.” A design constraint might be to implement in Java. A performance requirement might be to validate the customer id within 5 seconds.
Module 1 - Best Practices of Software Engineering

4. How To Catch Requirements Errors Early
Effectively analyze the problem and elicit user needs
Gain agreement with the customer/user on the requirements
Model interaction between the user and the system
Establish a baseline and change control process
Maintain forward and backward traceability of requirements
Use an iterative process
Create a ‘sharable’ model with customers
For a given iteration, all requirements need not be known; however, before developing that iteration, all requirements should be known.
No matter how good a job we do in trying to capture all requirements, mistakes will be made and users will change their minds. We want our development process to help us drive out errors as early as possible and to make sure users have regular opportunities to identify changes and to recognize their impacts.
Module 1 - Best Practices of Software Engineering

5. Problems Addressed by Requirements Management
Root Causes
Solutions
Don’t try to talk to all of the arrows on this slide (or the other 5 slides just like it). Pick one or two that are most important and elaborate.
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall development
Uncontrolled change
Insufficient automation
A disciplined approach is built into requirements management
Communications are based on defined requirements
Requirements can be prioritized, filtered, and traced
Objective assessment of functionality and performance
Inconsistencies are more easily detected
RM tool provides a repository for requirements, attributes and tracing, with automatic links to documents
Module 1 - Best Practices of Software Engineering

6. Practice 3: Use Component-Based Architectures
Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Verify
Quality
Model
Visually
Control Changes
SOFTWARE ARCHITECTURE IS A MUCH MISUNDERSTOOD DISCIPLINE
BY THE SOFTWARE INDUSTRY.
SOME SAY THAT SOFTWARE ARCHITETCTURE IS THE
DEVELOPMENT PRODUCT THAT YIELDS THE GREATEST ROI WITH
RESPECT TO QUALITY, SCHEDULE, AND COST…
Module 1 - Best Practices of Software Engineering

7. Software Architecture Defined
Software architecture encompasses significant decisions about the organization of a software system.
Selection of the structural elements and their interfaces by which a system is composed (packages, subsystems, …)
Addresses how the application will be built….
For the most part, it is part of ‘Design.’
Behavior as specified in collaborations among those elements
Composition of these structural and behavioral elements into progressively larger subsystems
Architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition
Architecture is part of design – addresses questions on HOW the system will be built.
Example of architectural concern: integration.
How will database B work with platform A, etc.
Very important artifact in an incremental development approach!
Because students vary in how familiar they are with the concept of architecture applied to software, it is best to get a sense of this from the students before beginning this section. If they are fairly unfamiliar, it helps to use the analogy to buildings or civil engineering. The more complex the building, the more critical a good architecture is. The longer you want the building to be useful, the more effort and expense you will put into the architecture. And in both of these cases, the choice of architect is critical.
Module 1 - Best Practices of Software Engineering

8. Resilient, Component-Based Architectures
Good architectures meet their requirements, are resilient, and are component-based
A resilient architecture enables
Improved maintainability and extensibility
Economically-significant reuse
Clean division of work among teams of developers
Encapsulation of hardware and system dependencies
A component-based architecture permits
Reuse or customization of existing components
Choice of thousands of commercially-available components
Incremental evolution of existing software
This is where we introduce the term “component” in a formal sense, so spend some time talking about components and give some examples. Java Beans is usually a good example to use and is very up to date.
If the question of reuse and OO comes up, the overall concept is that object technology enables development of components, but the unit of reuse is not an “object”, but a “component.” Object technology provides the development technique. The output is a component.
Module 1 - Best Practices of Software Engineering

9. Problems Addressed by Component Architectures
Root Causes
Solutions
Don’t try to talk to all of the arrows on this slide (or the other 5 slides just like it). Pick one or two that are most important and elaborate.
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall development
Uncontrolled change
Insufficient automation
Components facilitate resilient architectures
Reuse of commercially available components and frameworks is facilitated
Modularity enables separation of concerns
Components provide a natural basis for configuration management
Visual modeling tools provide automation for component-based design
Module 1 - Best Practices of Software Engineering

10. Practice 4: Visually Model Software
You may wish to lead a discussion about models and why we build models in general. For example, before building a bridge, the architect builds a model and has it reviewed.
We build models because the thing we are studying is so complex that no one can understand all of the details. A model leaves out all the details that are unimportant. It facilitates our understanding of the larger issues.
Develop Iteratively
Model
Visually
Use
Component Architectures
Manage
Requirements
Verify
Quality
Control Changes
A Model is a simplification of reality that produces a complete description of something
from a specific perspective.
We build models when we cannot fully comprehend the complexity of some things.
Modeling helps the development team visualize, specify, construct, and document the
Structure and behavior of a system’s architecture.
We will use a standard modeling language, UML (Unified Modeling Language).
Module 1 - Best Practices of Software Engineering

11. Practice 4: Visually Model Software
Capture the structure (static) and behavior (dynamic) of architectures and components
Show how the elements of the system fit together and collaborate to provide functionality
Hide or expose details as appropriate for the task
Implies a hierarchy
Maintain consistency between a design and its implementation
Promote unambiguous communication
Visual modeling for software is analogous to blueprints for construction.
Visual modeling improves our ability
to manage software complexity
Module 1 - Best Practices of Software Engineering

12. What Is the UML? The Unified Modeling Language (UML) is a language for
Specifying
Visualizing
Constructing
Documenting
the artifacts of a software-intensive system
Don’t go into detail on the UML here. We discuss it in more depth in the next module.
UML is an industry standard and is platform independent!
It defines a graphical modeling language for presenting models
and defines the semantics for each graphical element from different perspectives
Module 1 - Best Practices of Software Engineering

13. Diagrams Are Views of a Model
A model is a complete
description of a system
from a particular
perspective
We use UML to provide nine different diagrams
and five (4+1) major views: Use Case View,
Logical View, Process View, Implementation View, and
Deployment View
It is not necessary to discuss any of these diagrams in detail. The points to make are:
1. More than one diagram is necessary to represent software
2. The UML has made a tremendous contribution in giving us a common visual language to express these models.
All of these diagrams can be created using Rational Rose with the exception of the activity diagrams.
Explain:
Deployment
Diagrams
use-case
Scenario
Sequence
State
Component
Models
Object
Collaboration
Activity
Class
Know these!!!!!
Module 1 - Best Practices of Software Engineering

14. Visual Modeling Using UML Diagrams
Single, common modeling language used throughout
Maps the artifacts between business engineering, requirements capture, and analysis, design, and testing.
The point to be made is that the UML is the language we use to visually model. Since it is a widely-adopted standard, it facilitates understanding and communication of the visual models we create.
Activity diagrams are not shown on the slide. Activity diagrams can be used to model workflows in business process engineering.
Use-Case Diagram
Class Diagram
State Diagram
use-case 1
Actor A
Actor B
use-case 2
Customer
<<entity>>
name
withdraw()
receive()
addr
Domain
Expert
use-case 3
Deployment Diagram
send()
fetch() UI
Class
MFC
DocumentApp
- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼­¹ö ¹× µ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö
- À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ®
ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨
- À©µµ¿ì NT: ÀÀ¿ë¼­¹ö
RogueWave
Persistence
Repository
DocumentList
9: sortByName ( )
Window95
Windows95
Windows95
User Interface
Definition
global
mainWnd : MainWnd
Package Diagram
FileManager
Ŭ¶óÀ̾ðÆ®.EXE
¹®¼­°ü¸®
¹®¼­°ü¸® ¾ÖÇø´
1: Doc view request ( )
Windows L
Document NT
2: fetchDoc( )
Solaris
4: create ( )
gFile : GrpFile
¹®¼­°ü¸® ¿£Áø.EXE
8: fillFile ( )
Windows
ÀÀ¿ë¼­¹ö.EXE
Alpha
UNIX
user : »ç¿ëÀÚ
GraphicFile NT
fileMgr : FileMgr
3: create ( )
File
FileList
Mainframe
IBM
6: fillDocument ( )
µ¥ÀÌŸº£À̽º¼­¹ö
5: readDoc ( )
7: readFile ( )
repository : Repository
document : Document
Component Diagram
Forward Engineering (Code Generation)
and
Reverse Engineering
Collaboration Diagram
user
mainWnd
fileMgr :
FileMgr
document :
Document
gFile
repository
Source Code edit, compile, debug, link
ƯÁ¤¹®¼­¿¡ ´ëÇÑ º¸±â¸¦
»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
1: Doc view request ( )
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
¹®¼­ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼­
È­ÀÏ°ü¸®ÀÚ´Â Àоî¿Â
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
6: fillDocument ( )
7: readFile ( )
È­¸é °´Ã¼´Â ÀоîµéÀÎ
Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡
°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
º¸¿©ÁØ´Ù.
9: sortByName ( )
8: fillFile ( )
Sequence Diagram
Executable System
Module 1 - Best Practices of Software Engineering

15. Visual Modeling and Iterative Development
Those who have been developing software for some time may remember the early CASE tools of the mid-80s. They failed specifically because, while they facilitated visual modeling, they provided no way to automatically resynchronize the source code with the model, i.e., no reverse engineering mechanism. This had to be done manually, was expensive and inaccurate, and often led to the abandonment of the modeling tool after the source code appeared.
Animation notes:
The green explosion and the takeaway line appear on a mouse click. Before they appear, explain the cycle of iterative development. Then click the mouse and explain how design and code can get out of sync.
initial requirements
risk targeting
requirements
analysis & design
assessment
implementation & testing
deployment
Changes to Design?
Module 1 - Best Practices of Software Engineering

16. Visual Modeling and Iterative Development
initial requirements
Animation notes:
Initially, this slide looks just like the previous one. The green explosion and the takeaway line appear automatically after one second. Emphasize the importance of assessment, of not just automatically accepting the code changes that were made. For example, they may violate project standards or architectural decisions that were made. In that case, they would have to be reworks on a future iteration.
Animation: The explosion takeaway text appear automatically one second after the slide.
risk targeting
requirements
analysis & design
assessment
implementation & testing
deployment
What Changed? Are These Changes Acceptable?
Reassessment per Iteration?
Kill or Press on!
Module 1 - Best Practices of Software Engineering

17. Problems Addressed by Visual Modeling
Will use Rational Rose for creation / maintenance of these UML diagrams and use cases
Root Causes
Solutions
Don’t try to talk to all of the arrows on this slide (or the other 5 slides just like it). Pick one or two that are most important and elaborate.
use-cases and scenarios unambiguously specify behavior
Models capture software designs unambiguously
Non-modular or inflexible architectures are exposed
Unnecessary detail hidden when appropriate
Unambiguous designs reveal inconsistencies more readily
Application quality starts with good design
Visual modeling tools provide support for UML modeling
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall development
Uncontrolled change
Insufficient automation
Module 1 - Best Practices of Software Engineering