Introduction to Software Engineering

1
Introduction to Software Engineering

• CSCI 577a
• LCA Workshop

2
MBASE LCO Wrap-Up
3
Congratulations!

• Youre engaged to your project (LCO)
• Now on to marriage (LCA)

4
Suggested Effort Graph (for success)
total effort
Product demo
time
LCO
LCA
IOC
5
Effort Graph CS3156 S99
http//www.columbia.edu/cl363/research/images2.ht
ml
total effort
LCO
LCA
IOC
date
6
LCO where are you at?

• Success criteria
• Identify at least one feasible architecture

7
LCO ARB Common Pitfalls

• LCP 3.1 repeating guidelines
• LCP 2.2 no schedules, no specific tasks
• LCP 2.1 no schedule for lifecycle and stages
• LCP 4.1 effects of risk on schedule and
  responsibilities
• LCP 4.3 repeating guidelines
• FRD 2.1 not matching with OCD org. goals for
  value
• FRD 4 no risk exposure, risk mitigation
  feasibility missing
• SSAD architectural feasibility arguments belong
  in FRD
• SSAD behavior model not starting with OCD
  capabilities
• SSRDOCD goals R and S not referencing other
  goals and capabilities
• OCD 3.3 focus on changes to org. activities, not
  system use
• OCD project goals lt SSRD project goals
• OCD L.O.S. lt SSRD L.O.S.
• OCD Capabilities lt SSAD behaviors

8
One View Models Needing Integration
Success Models

• Win-Win Business Case Analysis
• Software Warranties QFD
• 10X Six Sigma
• Award Fees
• JAD RAD

Product Models

• Spiral
• Waterfall
• Risk Management
• Business Process Reengineering
• CMMs Peopleware
• IPTs Objectory
• Groupware

• UML
• CORBA COM
• Architectures
• Product Lines
• OO Analysis Design
• Domain Ontologies
• COTS GOTS

MBASE

• COCOMO
• COCOTS Checkpoint
• System Dynamics
• Metrics - ilities
• Simulation and Modeling

Process Models
Property Models
9
Getting From A to B
LCP
FRD
SSAD
SSRD
LCP
OCD
10
MBASE Integration Framework
11
MBASE Conceptual Framework
12
MBASE WinWin Spiral
13
Integration of MBASE System Definition Elements
Domain Description
System Analysis
System Requirements
System Definition
Statement of Purpose
Organization Background
Project Requirements
Project Goals
Organization Goals
Levels of Service
Levels of Service Requirements
Organization Activities
System Capabilities
Capability Requirements
System Design
Organization Entities
Component Model
Object Model
Operations Model
Activity Model
Behavior Model
Enterprise model
Interaction Model
Class Model
Operational Concept Description (OCD)
System and Software Requirements Definition (SSRD)
System and Software Architecture Description
(SSAD)
14
Candidate 577a Risk Items

• Personnel commitment compatibility ease of
  communication skills (management, Web/Java,
  Perl, CGI, data compression, )
• Schedule project scope IOC content
  critical-path items (COTS, platforms, reviews, )
• COTS do not match requirements
• Rqts, UI mismatch to Library user needs
• Performance bits bits/sec overhead sources
• Stakeholder expectation model clashes

15
Requirements and Expectations Domain Model
Clashes

• Easy/hard things for software people
• If you can do queries with all those ands, ors,
  synonyms, data ranges, etc., it should be easy to
  do natural language queries.
• If you can scan the document and digitize the
  text, it should be easy to digitize the figures
  too.
• Easy/hard things for librarians
• It was nice that you could add this access
  feature, but it overly (centralizes,
  decentralizes) control of our intellectual
  property rights.
• It was nice that you could extend the system to
  serve the medical people, but they havent agreed
  to live with our usage guidelines.

16
The Road Ahead LCA

• Success criteria
• Demonstrate that you are committed to a feasible
  architecture

17
Pre-wedding plans

• What do you need to do between LCO and LCA?
• Design
• Resolve all significant architectural issues
• Advanced prototyping
• Refine
• Resolve model clashes
• Add significant details
• Remove non-significant details - no fluff
• Schedule, roles, commitments, effort estimates,
  etc.
• Justi-fine! (Justify)
• Assure architecture is faithful to concept
• Assure value of system vs. stakeholder investment
• Reduce risk exposure

18
What does this involve?

• Several iterations through MBASE models
• Model integration and integrity paramount
• Refine WinWin negotiations
• Close out old issues
• Cover all win conditions
• Identify and deal with new win conditions
• Writing code
• Advanced prototyping to resolve risky
  architectural issues
• Head start on implementing critical requirements
  (for assurance, schedule, etc.)

19
Life Cycle Architecture (LCA)

• more formal, with everything tracing upward and
  downward
• no major unresolved issues or items, and closure
  mechanisms identified for any unresolved issues
  or items (e.g., detailed data entry capabilities
  will be specified once the Library chooses a
  Forms Management package on February 15)
• no more TBD's
• there should no longer be any "possible" or
  "potential" elements (e.g., Entities, Components,
  )
• no more superfluous, unreferenced items each
  element (e.g., Entities, Components, ) either
  should reference, or be referenced by another
  element. Items that are not referenced should be
  eliminated, or documented as irrelevant

20
Win Win Spiral Anchor Points
21
Common Subsystem Macroprocess
Development Life Cycle
Construction
Elaboration
Inception
Architecture Iterations
Release Iterations
SSR
IPDR
PDR
CDR
5
10
20
25
0
15
Contract award
Architecture baseline under change control
(LCO)
(LCA)

• Competitive design phase
• Architectural prototypes
• Planning
• Requirements analysis

Early delivery of alpha capability to user
RATIONAL
S o f t w a r e C o r p o r a t I o n
22
The rest of the semester.

• Remember the four MBASE project phases
• Inception
• Elaboration
• Construction
• Transition
• (Then you spend your life supporting it.)
• Elaboration ends approximately at the time of
  your LCA ARB. Then, construction begins after
  RLCA in CS577b (though you may start sooner than
  that!).

23
Get ready for LCA

• Tasks for LCA
• Finalize your OCD, SSRD.
• Get your SSAD to a point where you can construct
  something from it.
• Prove to us that youre organized enough to
  finish on time, in your LCP.
• Use your FRD to prove that the rest of the
  documents are sane, and that your project will
  work.

24
LCA 1 Finalize OCD, SSRD

• Finalize your OCD, SSRD so that your other
  documents can build on a solid base.
• Now that youve had one review, work out
  remaining open requirements with your customer.
  This may not be completely possible, so do your
  best.
• Remember that your OCD/SSRD can and should be
  agnostic toward specific implementations get
  the what of your project down, leave the how
  to the SSAD.
• Probably your OCD and SSRD wont have to change
  much between LCO and LCA. But if they do need
  to, make the changes soon, and show them to the
  rest of your group!

25
LCA 2 Finish your SSAD, 1

• Your SSAD is the most critical document in your
  LCA package/presentation.
• Remember, your goal is to demonstrate to use ONE
  architecture that your group can build and will
  satisfy the requirements.
• You may have had architecture options at LCO. By
  LCA, decide on one. You make this decision based
  on your customers input, advice from your TAs,
  and (in particular) a series of risk-driven
  prototypes (risk-driven means your prototype the
  hard parts).

26
LCA 2 Finish your SSAD, 2

• How to decide if your SSAD is good?
• Your SSAD is doing the right thing when it
  accurately maps the SSRD onto a set of
  components, each with a specific design.
• Your teams programmers should be able to take the
  SSAD and implement each object, making the how
  decisions in program code without wasting thought
  on the what of each object, and with confidence
  that the objects will, when assembled together,
  yield the finished product. (That is, your
  architecture should keep your programmers from
  thinking too much.)
• A good SSAD directly inspires your construction
  schedule dependencies should be clear, so you
  can identify which pieces have to be built first,
  and which can be built in parallel.

27
LCA 3 LCP, 1

• Your LCP is critical to finishing your product
  once you know how to do it (SSAD).
• Identify a few (2-5) iterations, or phases
• For each, identify specific tasks for each
  member, by name and role (In iteration 2, Fred
  will be constructing the User Interface API while
  Jane tests the DB interface constructed in
  iteration 1 (see SSAD 3.x.x. and IOC Test Plan
  2.x, 2.y).)
• For each, identify milestones (finished objects
  and components, test results, reports, reviews,
  deliverables, meetings).
• Set durations, and tentative specific dates, as
  best you can.

28
LCA 3 LCP, 2

• Things for specific sections
• In 4.1, Risk Management, identify the schedule
  effects (in terms of durations and dates of your
  iterations) if a risk item happens.
• In 4.3, Reviews, youre being prompted to
  schedule reviews other than the mandated LCO,
  LCA, IOC. Schedule formal or informal reviews of
  specific aspects of your project. Reviews might
  include your customer or a TA, or might be
  internal reviews among a subset of your group.
  The ends of iterations are good times for
  internal reviews.
• In general, be as specific, but realistic, as you
  can. This hard, but very important (and it will
  make your life easier in the long run.)

29
LCA 4 FRD

• Use the FRD to validate your process. In it, you
  can show how cool you are. And, you can cover
  your ---.
• In the business case analysis (2.1), dont think
  that your project costs nothing just because the
  customer doesnt have to pay out any money for
  it. It costs your time, and some of the
  customers. Show that the time expended will be
  worthwhile.
• In the requirements satisfaction section (2.2),
  show specifically how your system will implement
  the requirements, by referencing (in a table?)
  the SSRD and SSAD.
• In section 3, process rationale, show that your
  schedule and organization and your contingency
  plans are in line with the requirementsand the
  really core requirements.

30
Making that schedule

• There are several key goals for your project
  schedule
• Break the construction down into iterations, so
  youll catch overruns early.
• Leave time for testing, debugging, documenting,
  reviews and inspections!
• Schedule for maximum concurrency. That is, so
  that as many things may get done at the same time
  as possible.
• Make your schedule consistent with your IOC
  iteration plans and test plans.
• Be prepared for overruns. Leave extra time and
  resources, and have contingency plans ready.

31
Communicating schedules PERT charts

• A pert chart shows a flow of tasks.
• Check points are clearly indicated, but durations
  arent.
• There are several syntaxes. A basic one
• Tasks are represented by boxes, labeled by name
  and dates or duration.
• Time flows from left to right. Tasks that happen
  at the same time are aligned vertically.
• Arrows connect boxes to indicate how one task
  enables or gives way to another.

32
PERT example
33
Gannt charts

• A Gannt chart is optimized for comparing the
  durations and relative scheduling of tasks.
• Gannt charts arent particularly good at denoting
  checkpoints or other divisions of the schedule.
• Gannt syntax
• A timeline, marked with dates, runs from left to
  right.
• Tasks are listed by name down the left side.
• The duration of task in time is marked by a
  horizontal line.

34
Gannt example