Some notes for Software Engineering --
Practical Issues
by Herbert J. Bernstein
© Copyright Herbert J. Bernstein, 2002
Practical Issues
In the Introduction we covered a
lot of abstract concepts. Now we must consider the practical
issues of actually starting on a software engineering project.
Assume we have created a preliminary design and have some sense
that it is feasible. Now we need to create a detailed system
design and reduce it to a set a projects with a sensible schedule.
- Decompositions
- Top-down
- Object-oriented
- Bottom-up
- Apply both to the system and to the environment
- Project -- related set of activities (tasks) and specified goals
- Project Constraints
- Specifications
- Time
- Budget
- Personnel and other resources
- Policies and regulations
- Project dependencies
- Budget dependencies (finite pie)
- Time dependencies (must complete A and B before C can start)
- Tip: dependencies in creating code are not the same
as dependencies in execution of the code
- Specification of both input and output comes before
specification of processing from input to output
- Timelines
- Gantt Chart
- Horizontal bar chart
- Time on the horizontal axis
- Activities on the vertical axis
- Bar for each activity from start time to completion
- Arrows for time dependencies
- Markers for important milestones
- Pert (Project Evalutation and Review Technique) Chart
- Similar to Gantt Chart
- Focus on dependencies
- Critical Path
- Milestones and Deliverables
- Milestones as points in a project schedule at which performance will be measured
- Deliverables as products to be produced at milestones and project completion
- Milestones must be frequent enough to allow problems to be caught in time
- Milestones must be far enough apart to allow some work to get done between them.
- Software-specific issues
- In addition to project constraints (above)
- Performance requirements
- Compatibility requirements
- Skills and experience of available personnel
- Hardware and software platform(s) for the product(s)
- Network issues
- Database issues
- Security issues
- User language issues
- Development environment(s)
- Documentation
- Delivery mechanism(s)
- Training
- Writing code
- Start with a clear specification of what outputs should be
produced from what inputs
- Create samples of all necessary input
- Create samples of all necessary output
- Create a minimal program which can read and check
all inputs
- Add code to produce at least the basic structure of all necessary
output (don't forget error cases)
- Add processing functionality in small pieces
- Leave debug printout code in (disabled or as comments)
- Test and document each piece as you build it
- Test and document the overall program as you add pieces
- Yes, intermediate versions should "work"
- Use a version control system to save the program as it grows
- When you encounter a bug, don't just fix that bug, recheck the
entire section of code involved.