User:Hyad/SE/Test1

Activity Management

 * Identifying what needs to be done
 * Planning and scheduling activities
 * Assigning responsibilities for activities
 * Tracking them to completion

Requirements

 * Requirements must be determined OR Clients produce requirements
 * New development (green field project) OR Evolution of existing system

Software Process Models
(Lifecycle models) http://www.se.rit.edu/~se361/slides/SoftwareProcessModels.pdf

-models should be aids ot thinking; not rigid

Opportunistic approach

 * First Prototype --> Modify until satified <--> Think of Idea for improvement
 * OK for small projects, bad for big ones

Waterfall
-classic SE model -->Specification -->Design -->Implentmentation -->Integration & Development -->Maintenance
 * Requirements gathering & Definiton
 * Good: emphasizes importance of requirements, design, quality insurance
 * Bad:Must complete one stage before next, doesn't allow prototyping, testing is done only at end, it implies after product is finished-everything els eis just maintenance

Incremental

 * Requirements-->Design-->Implentmentation-->Testing, then you're done with Ver. 1
 * Requirements-->Design-->Implentmentation-->Testing, then you're done with Ver. 2...
 * Good:Customers provide feedback after each release, core functionality developed early on

Spiral
--risk driven

Requirements
http://www.se.rit.edu/~se361/slides/Requirements.pdf

Domain
-get a better understanding of your domain the clients will use the software domain
 * The domain is the general field of business or technology in which
 * A domain expert is a person who has a deep knowledge of the

Requirement
all stakeholders agree must be made true in order for the customer’s problem to be adequately solved.
 * Requirement: A statement about the proposed system that
 * Short and concise piece of information
 * Says something about the system
 * All the stakeholders have agreed that it is valid
 * It helps solve the customer’s problem
 * A collection of requirements is a requirements document.

Functional requirements
-Describe what the system should do
 * What inputs the system should accept
 * What outputs the system should produce
 * What computations the system should perform

Non-functional requirements
-Constraints that must be adhered to during -3 types:

maintainability and reusability development ex. Cost
 * 1. Product properties: usability, efficiency, reliability,
 * 2. Constraints on the platform and technology to be used
 * 3. Constraints on the project plan & development methods

User Stories
the system involved in each operation and the system responses
 * Identify the various operations performed by users on
 * Develop a brief narrative description of the steps

Types of Requirements Documents
for large systems are normally arranged in a hierarchy An informal outline of the requirements using a few paragraphs or simple diagrams A long list of specifications that contain hundreds of pages of intricate detail
 * Requirements documents
 * Requirements definition-
 * Requirements specification-
 * Requirements analysis never stops

Risk
impact customer satisfaction functionality / performance / convenience technologies properly? (if new technologies being used) =Prototyping and Risk= http://www.se.rit.edu/~se361/slides/Prototyping&Risk.pdf
 * Requirements risk: Missing key requirements and preferences that
 * Technical risk: Not sure if the product will be able to deliver on
 * Technology risk: Will the team be able to use the development
 * Design risk: Missing key design issues / wrong decisions
 * Market risk: Will it sell? Will customers like it?
 * Schedule risk: Will it get completed on time?

Prototyping
sequence to explain what would happen databases or interact with any other systems implementations of parts of the product risk associated with the project
 * The simplest kind: paper prototype.
 * a set of pictures of the system that are shown to users in
 * The most common: a mock-up of the system’s UI
 * Written in a rapid prototyping language
 * Does not normally perform any computations, access any
 * May prototype a particular aspect of the system
 * Prototyping involves building simple & quick
 * The major reason for prototyping is to reduce some type of

Several types of prototypes, depending on objectives

 * Interface prototypes (most common) mitigate requirements risk
 * Build a mockup of product interface to get user feedback
 * Minimal or dummy functionality
 * Implementation prototypes mitigate technical risk
 * Core product functionality to demonstrate feasibility of product
 * May have trivial interfaces and few additional features
 * Variation: Design prototypes, to understand design issues, study behavior
 * Technology prototypes try out use of new technologies
 * Build only a part of the product, or even something totally different
 * Demos are prototypes built to mitigate market risk

Types of Prototypes
+ Can use special “prototyping technologies” to build quick prototypes e.g. GUI builders, code generators + Don’t have to design prototype carefully + Coding can be more freestyle and unconstrained – Need to redo all the work + Prototype is just first version in incremental development • But need to be careful to use full product-style development process when building prototype – Prototypes change a lot early on, so design & code quality may deteriorate. Need to re-factoring /reimplementation as needed
 * Throw away prototype
 * Discard prototype, build product from scratch
 * Evolutionary Prototypes
 * Modify prototype into final product
 * Prototyping for elicitation of requirements (Demo)
 * Advantage: Customer knows exactly what to expect
 * Danger: Customers don’t know why it takes so long to go from prototype to product!

=Software Engineering Practices= http://www.se.rit.edu/~se361/slides/SEpractices.pdf

1.Activity Management
developed customer reporting and presentations…
 * Identify the activities involved in the project
 * Based on the modules/features that need to be
 * Include lifecycle activities: design, inspections, testing,
 * Create a project plan
 * Estimate effort involved and completion time
 * To make commitments to customer
 * To arrange for resources
 * Refine estimates based on past experience (estimated/actual) - Underestimation of effort is extremely common
 * Track the activities through to completion

2.Risk Management
� Identify list of risks at the beginning of project � Estimate “probability of occurrence”: how likely is it? � Estimate impact: how much will it affect the project? � Prioritize based on combination of probability & impact � Risk mitigation is only worthwhile for a few high priority risks � Involves investing extra effort now, so that the probability of risk occurrence is reduced, or so that the impact will be less if it occurs � Risks must be constantly tracked: checked to see if they have occurred and need handling, and whether new risks have arisen � Assign owner who is responsible for tracking the risk periodically and ensuring mitigation strategies have been implemented

3.Configuration Management

 * Manage concurrent modifications to files
 * CM tools have check-out / check-in concept
 * Check-in comments to provide history of changes
 * Concept of workspaces provides consistent view for builds
 * Others cannot build if you check in file with errors
 * CM tools provide individual workspaces for team members.
 * Check in only after fully developing and unit testing the module.
 * The shared workspace only has consistent versions of files
 * Cannot rely solely on tool to prevent all problems
 * Also need coordination between team members to make sure that features added to different modules work together


 * CM tools support “branching” – multiple concurrent lines of development
 * Useful if developing for multiple platforms
 * Also if delivering slightly customized versions to different customers

Processes
may also be other roles
 * Systematic series of steps to accomplish a task well
 * Represents “most effective way of doing task that will avoid future problems”
 * Example: Code inspection process (abbreviated version)
 * Arrange meeting and notify people
 * Send out doc to be reviewed at least 2 days before meeting
 * Participants must come to meeting prepared with lists of defects found
 * Have a moderator and recorder (to keep track of defects found) – there
 * For each problem found, discuss briefly if it is really a problem
 * “Accept” or “Reject” the bug, record information about it
 * After the meeting, fix the problems, and track its fixing
 * You can see that it is designed to avoid common problems: people coming inunprepared, open-ended discussions, bugs found but never fixed etc.

Quality Management
find 6 defects & improvement opportunities and retesting would take (say) 30 hours
 * Finding best possible way to get work done
 * More efficient ways to accomplish tasks that save effort overall
 * Ways to work that improve quality of results from task
 * Example: Inspections and reviews are known to be excellent quality practices
 * (say)5 people spend 2 hours each reviewing 500 lines of code, and
 * To find those defects through testing, then debugging, fixing them
 * We spend 10 hours to save 30
 * Incidental benefits: Familiarity with others’ code, in case they are unavailable; learn from each other; avoid mistakes in own code

improve consistency of coding practices in team
 * Defining good processes that avoid problems
 * Coding standards, to enhance readability & maintainability and
 * Document templates, to
 * Provide clear guidance on what to document
 * Save effort creating documents from scratch
 * Avoid forgetting important information content
 * Checklists, for checking that everything has been done
 * Tracking inspection & test problem reports to closure
 * Using metrics data to improve estimation accuracy, identify common bugs to be avoided etc.

Defining Appropriate Practices
The processes and quality practices chosen must be matched to the needs of the project
 * Large complex projects require more formal processes
 * Larger teams need more activity management
 * Geographically distributed teams need stronger configuration management, more formal processes and rigorous activity management
 * Business-critical and “risky” projects (more high probability high impact risks) need more risk management