1.redundencies - essential data structures are repeated at many places.But sometimes it becomes necessary to keep redundency for eg in protocol development an upper layer will need to maintain the states of the lower layer.The idea here is not optimization but necessity to physically isolate a layer that can even go into hardware from software space.
2.Incomplete understanding of system environment in which the software runs.for eg
multithreaded nature of entry points,semantics of the return values of entry points,presumption of a concept to be same as a similar one.eg tdi interface works only in synchronous mode,trying to use it as async.
3.function redundencies
4.trying to create monolithic design,need to create binaries that work together,clearly separated interfaces and datastructures
5.not caring about the dont do's of sw development
6.non focussed approach
7.not having roadmap
8.not packaging
9.not having test cases
Saturday, January 1, 2011
top down and bottom up development
1.Top down - within a period of time, minimal demoable product is made.After each successive period more and more features is added.So at each interval demoable
product is present.Progress is measurable at each interval.Design changes doesnt waste effort too much.
2.Bottom up - First demoable product takes time.multiple units work parallelly to
develop all the features.Integration and testing takes time.After the first stage things will be fast.The design has to be perfect from start otherwise the work done
will be void.
3.For TD approach, first interval will have the framework ready with few features.
Rest of the system development will fall into placeholders of the framework.
4.For time estimation - When deciding to add a feature or modify a feature,find how many .c files .h files will be affected,how many functions will be affected, if it
spans across 5 files and 5 functions it will defenitely take 1 day cycle of modification,review,testing.If its a new feature addition again idea has to be gathered for its imapact on the number of .c and .h files and code addition,review,testing cycle,again for (5,5) it will take around 2 days(because of white space filling code addition).
5.types of modification - no data structure addition/deletion with code changes,data structure addition/deletion with code changes
product is present.Progress is measurable at each interval.Design changes doesnt waste effort too much.
2.Bottom up - First demoable product takes time.multiple units work parallelly to
develop all the features.Integration and testing takes time.After the first stage things will be fast.The design has to be perfect from start otherwise the work done
will be void.
3.For TD approach, first interval will have the framework ready with few features.
Rest of the system development will fall into placeholders of the framework.
4.For time estimation - When deciding to add a feature or modify a feature,find how many .c files .h files will be affected,how many functions will be affected, if it
spans across 5 files and 5 functions it will defenitely take 1 day cycle of modification,review,testing.If its a new feature addition again idea has to be gathered for its imapact on the number of .c and .h files and code addition,review,testing cycle,again for (5,5) it will take around 2 days(because of white space filling code addition).
5.types of modification - no data structure addition/deletion with code changes,data structure addition/deletion with code changes
Subscribe to:
Posts (Atom)