Short Software Development Cycle (From 2 years to 9 months of OS/400, DB2 v5 to v6)
Configuration management vs Reuseability
Object-Oriented Design/Programming
Communication Skills
Hardware/software tradeoff
Java !
Divide and conquer
Abstraction (Layer Architecture, OS, 32bits to 64bits)
Explicit representation of complex relationships
Processes (ISO 9000)
Extensive verification and validation (Testing)
Reusability
Requirement analysis and specifications
Design
Architecture design
Module design
Coding
Testing
Maintenance and evolution
Understand requirements with Customers (Past problem report, development team)
Interview with users
Reading relevant documents (e.g. New standard of SQL, JDK)
Inspections (e.g. Manufacturing System)
Prototyping
Feasibility study
Project planning (Sizing of staffs (PM, PY), Resource)
User interface
Test case generation might be in this phase
Restructuring (Porting of old project)
A detail documentation reviewed by different teams (Marketing, Development, Upper management, Filed Analysis)
Functional requirements
Nonfunctional requirements
Maintainability
Readability
Reliability
Performance
Limitation and Constraints
Requirement items must be testable for functional testing
Can be formal, like Z and VDM specifications.
Can be informal, like English specifications.
Or semi-formal, like data flow diagrams or Object-oriented specifications.
Control -- sequence aspects.
Data -- entities, attributes, relationships.
Data flow -- input/output or transformation view.
Must support decomposition.
Must support abstraction.
Must be integrated.
by Parnas and Clements.
Waterfall model is too idealized, can not be practiced (Why ?)
But, we can fake the process and produce the documents as though we follow exactly the same process. It is the document produced that is important not faithfully following the waterfall model process.
In design documents, they recommended that we record the design alternatives, and the reasons for the acceptance or rejection.
Document-Driven Process.
D. L. Parnas and P. C. Clements, "A Rational Design Process: How and Why to Fake it", IEEE Trans. on Software Engineering, 1986.
Proposed by Barry Boehm
Similar to the Waterfall model
4 stages
1) identify the objective of the product, to design, buy or re-use
2) perform prototyping or simulation
3) developing and verifying the product
4) review everything so far, coding, unit testing, integration testing
Iteration of the four stages
Stress the iterative nature of software development
What is the disadvantages ? Compared that with the classic Waterfall model.
Practiced by Microsoft and many other companies
Often, they must produce a working prototype at the end of each spiral
How to pick the ideal spiral length ? MS sometimes picks 1 day, IBM Austin picks 1 month
Why? To avoid costly testing at the end
To allow meaningful evaluation by customers and end users (Beta, or ... let a real user to test it out)
Microsoft even practice daily build to make sure that they have a working system at the end of each day.
M. A. Cusumano and R. W. Selby, Microsoft Secrets, Free Press, 1995.
Can mean very different things to different people:
Prototype for feasibility study
Prototype for experimentation
Prototype for evolution
Prototype for requirement understanding
They represent FOUR different approaches.
Proof-of Concept vs Scheduling
Identification -- identify problem characteristics
conceptualization -- identify concepts
formalization -- design structures
Implementation -- design rules
Validation -- testing
From validation, revise identification, conceptualization, formalization and implementation
Systems used in medical field
Identification and conceptualization -- requirement analysis and specification.
Formalization -- design.
Implementation -- coding.
Validation -- testing.
Well known problems in expert systems (In testing and debuging and adding requirement)
Some proposed solutions:
Better knowledge representation
use natural language interface
explanation
knowledge-based revision
Building small prototypes
Problems must be small enough single persons can handle the job.
The system is for experimentation only, no need of maintenance or modification.
A tool is available for developing the prototype.
The expert system needs to be maintained to be useful in practice
It is better to have a rigorous development process with intermediate deliverables and traceability among them, and perform verification and validation at each stage
Use of any constructs, structured or not, does not guarantee the software developed will be structured
Proposed by many AI researchers.
Specification is supposed to be operational.
Semi-automatic transformation from operational specifications into a compilable program.
Feedback loops for verification and validation.
Modification is done by re-playing or re-deriving transformation.
Initiated by so called 4th generation languages
Often associated with database management systems
Useful for report generation, sorting, searching, queries (RPG ?)
Useful for certain applications such as banking or mathematical operations such as set operations
If it works, it can increase productivity significantly
Will not be useful for general purpose computing in the near future
Unless approved, vendors can not use this approach to develop military applications
All software artifacts are reusable including requirement items, design patterns, design items, code segments, and test cases.
Most large programs are domain-specific and involve many versions
Software development process definitions can also be reused.
This is a BIG deal !!!
Low-level software reuse
reusable objects
mostly primitive objects
Cut and Paste Code ?
High-level software reuse
reusable software components -- Microsoft Word as an object
Lotus eSuite DevPack
require a flexible software architecture
Application generators (NetObj, WinObj)
Object-oriented frameworks (IBM SanFranciso Project)
This is the way to shorten software development cycle
Reuse code (faster development)
Reuse platform (AS/400 32bit to 64bit)
Software Reusability
Program Generation
Graphical and user-friendly specification language
Commonality analysis
Software Development Process modeling
Layer architecture and deployment
Thinking about 5 to 10% in productivity improvement per year is now obsolete.
It is time to think about more productivity gain.
It will take some time for this technology to be widely known and practiced and we still have the time to master the technology.
By Prof Tsai
Multiple IBM Cleanroom methods. Why one? There are 3-stage Cleanroom and 4-stage Cleanroom with different associated techniques.
Present 3-stage Cleanroom method by H. Mills.
3 independent teams -- specifications, coding and testing teams, they can communicate via documentation.
No compilers will be made available to the coding team.
Why, is I tell you there is no compiler until 2 hours before the homework is handle in. Are you going to code much more careful ?
The specification team use a semi-formal specification languages to specify the requirements, the specification team will ensure that the specifications are correct.
The coding team will code the software without compilers and will inspect the code.
The testing team will perform functional testing based on usage, instead of coverage, using a statistical model and unit testing and module testing will not be performed.
Getting rid of compilers for programmers is an excellent idea -- best programmers often use compilers the least, they spend more time thinking.
Having three independent teams for different tasks is an excellent idea -- this forces each team to produce dependable products.
The problem requirements must be relatively stable.
This process is too rigorous.
This approach has been tried on small to medium scale projects only -- do most IBM sites use this approach in their software development?
We can analyze any software development process using the waterfall model.
Requirement -- design -- coding and testing are basically generic activities.
All the processes must go through these activities either explicitly or implicitly.
Use Divide and Conqueur
Can we skip R?
we may not know exactly what the user wanted
Can we skip D?
we may have unstructured design
Can we combine R & D?
the design may become requirements or assumptions
Can we combine R & D & C?
Hacking
requirement, design and implementation issues all mix together
Problem identification -- requirements
Program understanding -- requirements
propose design changes -- design
modification -- coding
re-validation -- testing
Software maintenance is essentially a repetitive waterfall model
All materials are from work experience, software engineering books and ideas & notes from my advisor in University of Minnesota