| PEARSON CONSULTING | SOFTWARE | SERVICES | PROJECTS | IDEAS | ABOUT |
Creativity helps
Basic writing skills help
If this sounds like writing, it is. Software design is like writing a book.
It needs an Architecture (storyline) and should be modular (chapters and paragraphs).
And like most good stories, it should have only one Designer (author) or a very tightly
knit group of collaborators.
Know what you are trying to do before you try to do it. Do not try to figure
it out later or you'll soon find out why the last 10% of code can take 90% of the
total time effort to write. And since 90% of the time budget has already been spent,
well...you know the rest of the story.
When in doubt, experiment.
You have a little project to design and code up a microprocessor sensor interface.
You whip out your UML tool and Model Design books and ... realize this thing is too
small to have an OS. In fact, it may not even have a 'C' compiler.
So? .... You just head back to basics: Data movement and CPU operations.
The job is to move data from the sensor digitizing circuit (internal or external)
to the output interface (parallel or serial stream) and maybe do some data processing
on the data elements. If it's also controllable, then add a user interface
(buttons, IR, serial port, etc.).
CPUs really only do a few basic things. Move data into the CPU, perform operations on
data, move data out of the CPU, and do conditional testing for program flow control.
Interrupts can be viewed as hardware driven tests that can alter program flow.
Lazy programmers spend an extra 5% of their time documenting their code.
Inexperienced programmers don't document their code and enjoy spending 50% of their
time trying to figure out what they did, why they did it, and what lead them to do it
before they can start to work on why it doesn't work.
Lazy programmers end up doing less work.
Why Software Take Longer
Unless you've done this type of project several times before, 50% of your ideas will
be wrong, 50% of what you do you will change, 50% of what you need to do you won't think
of until you need it, and 50% of your time will be spent on other activities.
No wonder developing new software take 200% longer to do than expected!
NOTE: This also applies to the usefulness of Peer Reviews. Reviewers will find general
coding errors, any functional error detection will be driven by what they think the code
should do.
The value of your work is in its ability to be used by others. (somebody has probably said this before)
Good software works because it passed testing. Great software works by design.
Training
Training needs to be provided that covers the processes and tools use by the project.
This would include the document control system, code version control, the compiler tool suite,
meeting protocols, communications standards, etc.
For projects that acquire 1 or 2 people at a time, briefing sheets should be generated and
a trainer assigned to brief the new team members.
For 3 or more people, a training session should be scheduled to present the information.
A training session should also be conducted as a review for all team members once a year.
The session could cover all areas at once since it is a review.
Note Taking during debug
Use WordPad or other such light weight editor to record your trials and tests. You can
cut-n-paste settings to it to easily repeat prior tests and configurations.
Use one file per day, per week, or per problem and include the date in the filename.
Example:DB_conIO_080319.ccon I/O debug for Mar 19, 2008
If you try something and then remove it, don't delete the entry. Use strikeout instead. This
preserves your thoughts while you were debugging and can be reviewed later for analysis.
Put ?? in front of a line commenting a test or change note.
Put a ## in front of a line to record a result.
Example:
?? Change process order to scan block for zeros before processing
## minor timing improvement (2.6 us)
Experiment
When you encounter or develop a new code process, try it out before designing it in.
Say it's a message handling protocol. Write a bit of test code to use it to pass messages
between two or more code modules. This gives better insight into its capabilities and
limitations. It may also produce other ideas about how best to apply it to the design and
may even reveal new uses for the protocol.
Development Environment
The stability of the development environment is the most important concern of a software
manager. Its configuration and setup should be tightly controlled and well documented.
Setting up paths and environment variables can be tricky and complex sometimes and once
done, the process and decisions made at the time can be easily forgotten or leave with
the person that did the setup.
Paths to libraries and include files should be readily available to programmers.
Management
When assigning a task, provide an estimate of hours, days, etc, that you think the
effort will take. Then multiply by 3 to get the earliest possible time, date it could
be completed by assuming that the recipient has no other tasks.
Most work estimates are bad guesses, but the more you make, the better you'll get. After
awhile, you may only have to multiply by 2.
A manager should be able to describe, for each of their workers, what primary tasks should be completed for the week and for the month.
A manager should be able to estimate how much time is needed each day to be spent on answering e-mails and establish a time limit trigger to raise an alarm if this time starts to get excessive. This concept can also be extended to weeks and months to help manage time spent in meetings, presentations, vendor demos, etc.
The Manager as a Choreographer
When a manager has a vision and insight as to how their group fits into the overall
organization, they should be able to describe the average day of their any of their
subordinates. This is especially helpful to new hires in that it helps them organize
their day and set up daily routines that help them get in sync with the rest of the team.
The manager should also insure a degree of interaction between team members. Even though
each person may be assigned specific task, these tasks are rarely totally independent.
Therefore, some minimum amount of daily or weekly interaction is useful to maintain a
cohesive effort that moves the project forward and minimizes road blocks and surprises.
(It also gives the team a better chance to meet milestones, gates, and checkpoints.)
Another analogy is that of a Conductor. The 'music' of the code should be harmonious,
not a cacophony, blending of efforts by all of the team.
Questions
Does your project have well defined deliverables?
Do you know what this weeks goals are for each of your subordinates?
Do you know what the major risks are to your project and what your mitigation strategy is
for each of them?
How do you give the few experienced programmer you have a way to oversee the design
efforts of the less experienced programmer? Use the 1 day, 1 week process.
After giving a design assignment, meet in 1 day and have the designer give a 30 minute talk
on their approach, their concerns, identified risks, and other basic design thoughts.
If they show an understanding of the problem, then meet in 1 week to see a development
plan and estimate. If not, spend an hour showing them what they should have done, then meet
in 1 week.
If the plan is acceptable, let them proceed, otherwise assign someone else or spend a day
in training showing them what they should have done and how they should have done it.
Requirements are used to tell someone else about your design and to let them fill in the method of implementation.
Getting New Team Members Up to Speed
Any program, larger than a few people, should have an UNCLASSIFIED briefing for new team
members. This briefing would describe the overall system and the area that the new team
member will be involved in or responsible for. The CLASSIFIED sections can be presented
as 'black boxes' and discussed from an interface or basic processes level. This briefing
should also be reviewed monthly by a systems engineer to keep it up to date as the program
evolves.
Time Management
Normal week:
Friday should be a clean-up and reflect day. Do documentation that's been put off, clean
up code, plan the next week's activities, etc. If everything is humming along, crank out a
bunch of small code functions or modules to help fill in the status sheets.
Crunch week:
Friday is used to prep for the weekend. Set goals and coordinate resource needs to minimize
wasted time.
Management Warning Flag
Unless the project is a purely research or exploratory effort into new technology, major
work efforts that seem to pop up out of thin air tends to signal that the design has not
been well thought out. If this happens enough times, the project team can generate a
feeling that the design leadership does not know what it's doing and that work estimates
have no valid basis.
If this feeling sets in, then work efficiency and enthusiasm will diminish. The only remedy
sometimes is to replace the design lead.
Estimation
The goal of estimation is to make an educated guess of how much work needs to be done.
Once a rational estimate of work is available, THEN a schedule can be generated based on
resources that will be applied to the work effort.
These are two DISTINCT and SEPERATE tasks. They are mixed together only at the peril of
the mixer.
An important part of the estimation process is the documentation of the justification
for each component of the estimation. Any adjustment to the final estimation has to be
weighed against the justifications used for the estimate and reflected in the changes
to those justifications. The justifications are the basis of the estimate and are the
difference between a random guess and a rational estimate.
Teams
Whenever possible, try to work in a team. Discuss what you've done and how you did it
within your team.
Learn from their methods and have them critique yours. No one knows the best way to do
everything and anyone can make a mistake.
Peer review is a fast track to better programming.
Team Leaders
It has been stated in books on project management (need ref) that a good team with a
poor leader will do poor work and a poor team with a good leader can do acceptable work.
Teams usually rise or fall to the level of their leader.
SCRs, SCCBs, and CM oh my
These have to be the scariest acronyms for software people. The main problem
is that they usually get rolled up into processes that try to do all of them
and everything else at once. There are three distinct concepts here. They are
Change Control, Change Management, and Configuration Control and based on what
phase the project is in, they have different goals.
Change Control
During Design Phase, change is an ongoing process. The job of the coder is to
keep changing the code until it meets the description of the design. The job
of the designer is to keep changing the design until it meets the intent of
the requirements. This process is ongoing because no design is 100% complete
or 100% perfect until the product has been retired and is no longer in use,
and sometimes not even then.
Change Management
Change Management varies in its focus during the project. In the Design and Coding
Phases, where change is rampant, the focus is on monitoring the amount of change
activity going on and characterizing the changes. Unless things are really chaotic,
not much is done to restrict change. However, after these phases, changes in design
or code can have a more serious cascading effect on the project. Here, the manager
needs to carefully manage change and assess its impacts before allowing change to
occur. This is the primary realm of the Software Change Request (SCR) and the Software
Change Control Board (SCCB). These are formalized processes that are needed to control
change and to minimize potential adverse impacts to the rest of the project.
Configuration Management
One of the major complications of Configuration Management (CM) it that people lump
Change Control and Change Management into it. The proper view of CM is that it does
not matter how the changes came about, but that the snapshot-in-time or revision can
be replicated as needed. CM should focus on Snapshots in time, Repeatable code builds,
and Version control.
Design By Vision
Assume the system is complete and running as expected. Now, start describing how to
interface to it and how it accomplished each of its tasks. Continue describing, in
detail, what each module does until you get to a list of suggested or required
functions that would be needed. No fair having a box that says "And then a miracle
happens!".
Example questions to be answered:
Designing a Library
It's a good idea to have one file per function in a library. This will minimize
the memory impact for each function. If more than one function is in a source file,
the object file will be much larger than it needs to be. It also makes maintenance
and re-verification, when changes are made, easier.
Not as important for desktop applications, but can be a life saver for memory
constrained embedded ones.
The Friday Review Lottery
Everyone is given a chance to display work product(s) they completed that week. This
can be a lunch activity. The workproduct can be code, a document, or what-ever.
Three minute maximum presentation.
Everyone secretly votes for the person's effort, not the person. No voting for
yourself. Have fill-in ballots available.
Scoring
-1 Needs work or not really up to standards (this is an optional score)
0 Expected level of effort
1 Good effort
2 Excellent effort
3 Wow. That's really neat. I can use that or it will help in what I do.
Tally the votes and rank the presenters.
Put 10 (adjustable) tickets in a bag with one ticket marked HALF-DAY FRIDAY or
ONE-HOUR OFF TODAY or other similar prize.
The highest ranked person gets first draw. If not a winner, replace the ticket.
The next ranked person then draws and replace if not a winner. Repeat for the
top 50% of the participants (round up if odd number).
This allows people to present their efforts and shares knowledge between groups.
It can also include admin and other areas, not just developers.
It can be a half-hour lunch time (10 presenters) or longer.
It is meant for small teams, but could be applied to small groups of teams, or
used at monthly tag ups. Obviously, times, scoring, criteria, and prizes are
all adjustable.
The Confidence Survey
What's the probability that the project will finish on time? or work at all? An
anonymous survey of all of the project staff might help.
The Power of the Software Project Manager (SPM)
If processes are to be enforced to improve productivity, the SPM must have the
power to cancel a project if it gets out of control. Without this power, which
is needed if the SPM is given the responsibility for the company's investment
in the project, the SPM has essentially no control over designers and developers
that may have stronger personalities, more seniority, or greater company influence.
If the SPM is relegated to a position of bookkeeper and progress tracker, then the
well documented and presented spreadsheets will be a fitting legacy to missed
deadlines, cost over runs, and the evidence to support the lowest ranking of CMM,
CMMI, EVMS, or any other level of process.
Iterative Development or Spiral Development Lifecycles
Using the design, code, test, add new feature, repeat does not mean that you can
just throw a design together on a best guess of the day, hack it together, try to
get it to work, then throw more stuff in and repeat.
Iterative and Spiral development methods are formal types of prototyping used for
risk mitigation. They require careful thought in the design phase of each cycle
as to what the most critical risk areas are and what code is needed to mitigate
those risks in the most effective manner. Effective is the operative word here.
It can mean fast development to answer an interface risk, testing a design concept
for robustness against failure due to unconstrained data inputs, getting early
feedback from the customer on a proposed GUI design, or any number of risk reduction
methods. If used to get a product out the door with a minimum set of functionality,
then they are more like the Agile process, but that too is a formal process that
follows well defined methods and required activity.
The bottom line here is that all valid processes require careful upfront thought
of the design and planning of the work effort to be efficient and effective. Always
think through the entire lifecycle of the work product and not just the grand idea
of the day.
E Pluribus Unum "Out of Many One"
One of the most important tasks of a design lead is to decide on the overall
architecture or design philosophy to be used for a project. Studies have shown
time and again that the best solutions to complex problems come from groups rather
than from an individual. Since the group is made up of individuals, the design
lead's problem is to extract the best parts from all of the individual ideas and
combine them into a stronger overall solution. The operative word here is "extract".
Care must be given to not filter the ideas. Few ideas are ever bad, they can however
be inappropriate or non-applicable. The assumption is that the person offering the
idea thinks that it is applicable to the solution being sought. Ideas are based on
assumptions and if the idea is invalid, a look at what assumptions were made can be
much more helpful than just rejecting the idea outright.
A job applicant once remarked that one of his unique skills was the ability to extract
a strong good idea out of many weak ones. Not a bad skill to have.
The Need to Code before the Design is Completed
Assuming a Top-Down approach, design until you get the feeling that what you have
may not work as expected, then implement what you've got to verify the design, up
to this point, and validate assumptions made. It also gives you a better "feel" for
how the system will work. This point usually occurs when the design is becoming so
detailed that your pseudo code is starting to look like the language the project is
to be written in. Other indicators of reaching this point are the need for hardware
drivers to get real timing data, user interfaces or GUIs for user feedback on "look
and feel", network interfaces and protocols to check data flow, etc. It can also be
a good basis for verifying the tool chain to be used.
The one other thing that drives this point is that many designers used to be programmers
and would like to take a break from the mental effort of design to the more mechanical
effort of coding (assuming a good design document). This also gets back to getting a
"feel" for how the design will come together and helps clarify the designer's vision
of the final product.
Shalls come from requirements, wills come from design decisions
Shalls are normally based on Customer requirements, but can also come from business
decisions, system design decisions, and other higher level project needs.
Wills are used to lock down architect and design tradeoff decisions. These need more
"pedigree" support than 'shall' based requirements.
If the product is viewed as a collection of black boxes, requirements can easily take
on a layered aspect. The requirements at a specific layer only relate to what happens
outside the box that they as applied to and how the box will respond to input and
possibly the formats of the data that move in and out of it.
If the overall architect requires something specific about how the box works, then this
should be described in detail, with justification, in a concept or theory of operation
document that is referenced by the requirement.
Approach, Design, Implement
Discuss with others the Approach that will be taken to develop a Design or for complex
projects, an Architecture.
Once approved, discuss with others the Design that, if implemented, would meet the Requirements.
After the Design has been approved, discuss with others the implementation that has been
done to fulfill the Design.
Each of these can also have an Approach, Design, and Implementation series within them.
The discussions held within these phases can range from informal meetings to full blown
presentations. The point is to have some form of discussion with others, preferably
stakeholders, throughout the life of the project to keep focused on the goal of the
project and to uncover, sooner rather than later, issues related to that goal.
Herding Kittens or Orchestrating the Design
In more than a few projects, the Software Project Manager (SPM) ends up trying to guide
a number of seemingly independent entities that are supposed to be working towards a
common goal. A common thread that arises in post-mortem analysis is that the SPM assumed
that their Technical Leads and people assigned to them knew what they were supposed to be
doing. Yet, in digging deeper, few instances could be found where the SPM was verifying
this assumption.
There are various items to help orchestrate a project. The Software Development Plan (SDP)
is a key document that everyone on the project should be familiar with in that it has the
overall schedule, resources, and methods being used. Work Instructions should be the first
place people go to for answers of what process to follow to do something.
Does everyone on the project know where these documents are and what they contain?
Good architect and system level design documents help focus design groups to play well
together in that they are the basis for discussing interfaces and data flow between
modules in the system.
Are interfaces designed first and are they well documented before the core processes are
developed?
A well thought out design structure can limit independent wanderings to a more focused
goal of the specific module and support for its interface to the rest of the system.
The SPM can get verification of their assumptions by scheduling goals and sub-goals that
focus on filling in the design architecture and calling for informal reviews to discuss
what are we trying to do and why is it not getting done.
Master/Apprentice Programming
Have no more than one or two Apprentices per Master or your Masters will not get much
of their own work done.
Masters spend a minimum of one hour per week with their Apprentices in individual
one-on-one meetings. These can be in a conference room with white boards or at either's
work station. The emphasis is on information exchange, hence the white boards and work
stations.
As with many one-on-one training systems, the topic is along the lines of "How are
you doing this" vs. "How I do (did) this" in a corrective, suggestive, and evaluative
context. Some times the Master can learn from the Apprentice.
Processes
In general, and from experience, most processes are developed by people who never have
or had to use them. At the higher levels of certification, the capabilities and maturity
groups require that processes be developed according to a written process and all
processes are to be tested with focus groups or small targeted projects to validate the
process BEFORE it is imposed upon the masses.
The arguments of "Follow the process or Get the work done?" can be minimized by having
well thought out processes AND having the people who will use the processes provide
feedback before being tasked to follow them. This can lead to a smoother transition
from old way to new way and gives a greater probability that the new methods will be
followed and adopted into the corporate culture.
In addition to all of the above, do not forget to plan how training will be managed
to maintain the processes.
Software Environment Planning Using First Principles
The software development environment should be set up based on first principles of
the business requirements. Here are some examples.
There are many more first principles and most project include several. Many times they conflict with each other and trade-offs must be made. The basic approach is to list all of them during a team planning session and prioritize the list. This should result in a good reference to help in planning the software development environment.
Project Planning Using First Principles
Training Session Example
Target: AARAM Missile Radar Head
What are the most important systems features? (Marketing Engineering)
List these for display.
What are the most important systems level capabilities? (System Engineering)
List these for display.
These are two different areas although they can impact each other. They must
be kept separate to allow a stable design to be developed.
Discuss this concept.
Improving the Quality of Software Engineers
Software Engineers should go through the same process as medical doctors. There should
be an internship at any company they work for that consists of learning the current tools,
development environment, and integration processes that are standard for that company. They
also learn how development teams work, the review processes, and design practices that are
acceptable.
Four Stages on Using Procedures from "Action in an Organization"
(Nels Pearson,1987)
When tasked to do activities for an organization, rather than complain about how things
are done, try these four steps.
Evolution vs. Intelligent Design: Better Software Through Active Leadership
Early in a project, it was found that helpful information could be sent to the output window
of the debugging tool by use of the printf() function. This is a common practice in many software
projects. As the project continued, more and more programmers used this method to provide status
and error information about their section of code. Because this type of output was not planned for,
it "evolved" into a non-uniform jumble of output text that few but the originators could decipher.
Making The Hardware Team Happy
If you want to please the Hardware Group, insist that the system run "Light the LED" code first. By
demonstrating deterministic control over the hardware, the majority of the problems later on can be
arguably related to software. Having a stable and well tested hardware/software interface early in
the project can let software engineers focus on software and hardware engineers focus on
hardware. The Hardware Group can also run the "Light the LED" code to verify that they haven't broken
the interface that the software relies on.
For hopeless projects, at least try to use better bubble gum, bailing wire, or duck tape each time you're ask to make a change.
Integrate Hardware and Software Early and Often
Few things are more frustrating to Software Engineers than unstable or faulty hardware. Good hardware,
like good software, is rarely successfully developed in isolation. Many projects are parallel
efforts of developing new hardware and the new software to go with it.
One sub-section of the Integrated Product Team is the Hardware-Software Interface section. This
section is responsible for developing test suites to verify that the hardware will perform at
directed by the software. The section, for small projects, could also be responsible for the
development of the hardware specific drivers and hardware development test code. A key area is
working with the hardware engineers on developing the hardware interface definitions to minimize
the complexity and improve the robustness of the hardware interface drivers.
They can also be involved in developing simulation hardware and software to help systems engineer
model the product to explore proposed module interfaces and system performance.
Computer Programming
Is the ART and SCIENCE of moving the bits in the computer's memory from one area to another and
sometimes changing their states before or after they move. The ART is picking which SCIENTIFICLY
proven method to use and being able to justify why that method was the best.
Meetings: Donuts and Cookies Rule
As a token effort to show concern for employees, the company (under the Employee Moral Charge Number)
should provide donuts for any meeting held before 9am and cookies for any meeting held after 4pm.
Nit pickets could exclude meetings called for 9:00 or 16:00 and argue that the meeting times have be
before or after the times stated.
Others are the Lunch Meetings Require Pizza and the Deli Sandwiches or Take-Out For Weekend Workers rules.
The Architect, The Carpenter, and the Team - A Model for Product Development
The Architect knows exactly what the end product will look like in terms of structure, performance,
features, interfaces, etc. The Architect can answer any question the customer could raise as to how
the end product will meet the customer's expectations. These questions are not limited to the
product itself, but include support, test, training, maintenance, etc.
The Carpenter knows what parts and pieces are needed to provide those characteristics and how to
build those items.
The Team includes the administration and managerial support to generate a development project.
Logistics, resources, personnel, scheduling, monitoring, and all the worker bees make up the Team.
In a modern view, the Architect might be the Chief Systems Engineer. This person is the principle
customer interface for all requirements and technical obligations. If it pleases the Architect,
it will please the customer. The Carpenter might be the Chief Software Technologist or Project
Technical Lead. This person is responsible for leading the effort to develop the technology
needed to meet the Architect's vision and works closely with the Architect to insure that
that vision is technically feasible.
In a large project, both the Architect and Carpenter will lead small groups of leads that
in turn command one or more small groups. (i.e. The Team)
Another view, from Sports, is to see the Architect as the Team Manager, the Carpenter as
the Team Coach, and The Team as the Players and the Front Office. Even here, there are
sub-managers, sub-coaches, and lots of others.
The KEY point is that this model is based on three elements: Someone who knows what needs
to be done (The Architect), someone that knows what it takes to do it (The Carpenter), and a
bunch of people to get it done (The Team).
How to Succeed in RADAR without Really Trying
Model your system first and explore all the data paths.
Simulate any hardware that doesn't exist.
Show that your model will pass the data from end-to-end in ALL of its configurations, modes,
features, and options.
For complex hardware, assign a software team to develop drivers and FULLY exercise the
hardware so that no surprises occur when the operations software is applied using those drivers.
Replace simulated modules with real hardware once it has been verified and integrated with
software drivers.
Make sure that interface documents are stable as early as possible since any changes
could ripple through the entire system and cause all prior testing to be nullified.
The Easiest Way to Get People to Work
Make a Work Queue (WQ). Each task is described and has completion criteria. All notes,
bug reports, test, etc. are added to the WQ object so that if someone else wants to
continue the effort, they have all the information they need.
(Author's note: I used a similar method of assigning work in the mid-90s where I would
list the functions needed for the week and include a list for functions needed next week.
A list was generated for each programmer. If they finished this week's list, then they
could start on next week's.)
The Great Divide: Turning Developmental Code into Product Code
In many cases, developing software is like scientific study. An idea is generated based
on some prior knowledge and experiments are performed to verify the idea. Since the main
emphasis is to verify the idea, less effort is made regarding structure, robustness, ease
of use, performance, and quality in general. (see also Why Software Takes Longer).
Unfortunately, many managers think "The code works so therefore it's done, right?." Wrong.
About the only code that could be "done" in this context would be a quick "Hello world."
program to show someone how to compile and link using command line gcc.
Deliverable code for a product requires a vetting process with a level of documentation
consistent for its use.
Using first principles (see also Software Environment Planning Using First Principles),
generate a prioritized list of characteristics that the product software must have and
why and then use that list to qualify code for release.
Example: Robustness
Fail-Safe or Fault Tolerant: Should the software fail safely and stop or should it try
to recover from errors and continue to run?
Run Time Checks: At what level of the code can the inputs be trusted such that run-time
checks are not required on the input data?
Now, back to the main topic. Consider a two stage process: A loosely controlled code
development processes to discover how to do the software task and a tightly controlled code
development processes to convert the developmental code into a deliverable product.
Demos can be made with the developmental code, but only the output of the tightly controlled
process is allowed to be released.
The advantage to this method is that visibility is gained quickly as to which ideas work
and how the code modules interact without the overhead of formal peer review, formal
documentation, formal configuration management, etc. on code that may be thrown out
or mostly rewritten in the next day or week. Why? Because it is theoretically impossible
to predict exactly how software will interact until it is run on a system.
However, once those interactions are understood, the process of refactoring the code
into a robust product is fairly straight forward. And the insight gained should allow
for a better solution, if needed, to be generated.
Design reviews can now be conducted based on evidence rather than conjecture. Module
interactions can be analyzed and interfaces can be engineered rather than guessed at.
Quick Requirements Check
Walk through the requirements and put together a strawman design that would meet them.
Indicate how each requirement would be tested. How close to the reference architecture
did the strawman come? What 'holes' were discovered?
Viewing the Future as the Past
This is a planning technique that can help generate better development plans, uncover
hidden tasks, and unforeseen project resource requirements.
Gather your project leads and senior staff together and set the clock to one month after
the delivery date. Now, have each person try to describe how their area of the project
went. Example topics to cover could include:
Follow on Projects Require Follow on Expertise
Many projects leverage off a prior project by extending its features to meet a
new mission statement or develop a new mode of operation to be used with its
core capabilities.
Unless the base project was completed to a finished and deliverable product (i.e.
fully tested, independently buildable, and was well documented, both technically
and with user guides, manuals, and examples), the new project team should include
members of the base projects development team to insure that it has the corporate
technical knowledge base to succeed.
The Short War
Planet Noehtyar and planet Yugwen were moving twoards war and both embarked on
upgrade projects for their military.
Noehtyar's development system used a matrix model where the section managers tried
to support groups of multiple project engineers without knowing the details of what
those engineers did, but only the basic skills that they needed, and used functional
managers that didn't need the technical expertise to understand their projects but
focused on tracking schedules and EVMS charts.
Yugwen's used a hierarcal model where the manager at each layer of the overall
structure had the expertise to understand the technical aspects of the projects
and the authorization to select engineers with the background and experience to
do the detailed work of the next layer below. Based on their project experience
and technical background, they could evaluate their schedules, come up with
probabilities of success, adjust resources as needed, and used their EVMS as a
tool to validate changes made.
After five years, Noehtyar was ready to deploy their system that had most of the
initial features and many lesser ones that were added in the last year. However,
Yugwen had deployed their system three years earlier and had been continually
testing and training with it.
It was a very short war.
Six Sigma
Why is it difficult to generate a six sigma project topic?
If you have been evaluated as having an understanding of six sigma methods, why
do you need to develop your own project to demonstrate that knowledge?
What's the difference between writing a procedure, that should have been part
of the Software Development Plan (SDP), or generating a file management utility,
that should have been part of the programs development process, and a six sigma
project that does the same thing?
Asking non-manager personnel to come up with their own six sigma project is like
asking a private to come up with solutions as to why the war isn't being won.
A private could comment that the guns might work more reliably if the ammo wasn't
dropped in the mud, but shouldn't the sergeant already know that? Should the private
be expected to evaluate the deployment of troops and suggest an evaluation process
to determine the effectiveness of the strategy? How well would that be received at command?
Why aren't managers creating lists of tasks that, although not covered by their
contacts, could improve productivity or reduce waste on their program? Self-interest:
No one likes to admit that their program processes need improvement.
Problem Statement:
Most of the meetings that I have attended, at the project level, did not have a
written agenda, resulted in no decisions made, no actions to be taken, and did
not have meeting minutes recorded.
Figure a thousand dollars of productivity spent for each meeting without any record
of value received.
Would it be a six sigma project to suggest investigating ways to improve meeting management?
Model Based Schedule Tracking
Use a System Model to track progress by indicating the status of its infrastructure
and the components within the model.
Generate a block diagram of the system and highlight the infrastructure components
and all of the I/O and processing modules.
Flag each of these areas with Green, Yellow, or Red as used for EVMS tracking. Could
include White for Not Started. They could also be marked as to Phase (design, code &
test, released, etc.)
Every status meeting now focuses the team on what the system is suppose to do and how
it is doing it.
First level of operability: Passing data from end-to-end
Searching for the A Team
Reducing Wheel Reinvention with Effective Reuse of Corporate Knowledge
Successful programs are usually the results of key individuals leading others to
do or themselves performing outstanding work. These key individuals are also the
main repositories of the corporation's knowledge on how to successfully complete
a program.
Effective Use of Your A Team People: Three Columns
| Successful Programs | Key Individuals of the Past Involved and Expertise |
Where are they now? |
| -- | -- | -- |
Use my form to tell me what to do
I made the form and put in the boxes, sections, and areas that need to be filled in
to provide the information that I will need to get a job done.
Your form is based on what you want done, not necessarily on what I need to get it done.
My form will also contain areas for the relevant information from your form.
When I accept my completed form and agree to do the job, I am saying that I have all
the information that I need to do your job for you within the time agreed to.
Giving me your form is just an indication that you would like to discuss a job that
you would like done. There is no commitment being made on my part.
Can Reuse Succeed?
Process of assessment
1. List main products lines.
2. List primary products and show their architecture.
Note evolution or pedigree.
3. List product subsystems and show their architecture.
Note software language, OS, hardware, processor, memory, environment (airframe, desktop,
missile, space, mobile)
4. Evaluate reuse effort.
What was reused? Architecture, design, code, test system, external support, etc.
NOTE: The experience of developers can also be reused, but you have to talk to them.
Question: Did the Architect/Design Lead talk to anyone who has worked on this type of project?
(see Searching for the A Team)
hmm...more thoughts
Ultimate reuse: Code library
Typical reuse: Source code examples.
Typical reuse: Reference designs with supporting theory papers.
Typical reuse: Project document examples. SDP, SDD, PDR slides, CDR slides, STP, etc.
Typical reuse: People who know how to do this.
Survey
1. What items do your projects typically reuse from past or current projects?
MA: Project documents like the Software Development Plan (SDP) or a Software
Test Plan (STP). Source code examples, if well commented. Third party libraries and reference manuals.
2. What would you like to find in a Reuse Repository?
MA: Project documents with comments as to why selections or decisions were made
for the various document sections.
Source code examples with notes as to structure, variable use, and algorithm selection decisions.
Useful code libraries with reference manuals that includes examples of use for each function.
3. What would make a Reuse Asset useful to your project?
a. Code library asset.
MA: Should include verification suite or test plan. Source code would be useful also.
Treat as open source.
b. Source code asset.
MA: Well commented and should include a developers notebook file to help understand
the coding style and structure.
c. Reference design asset.
MA: Notes on decisions made in the design tradeoffs, pros and cons, and considerations.
Memory use analysis. Run-time estimates, etc.
d. Project document asset (SDP, SDD, STP, SR, ADD, etc.)
MA: Project documents with comments as to why selections or decisions were made for
the various document sections.
e. Subject Matter Experts (SME) list.
Contact information and background.
4. Does your project consider using reuse when developing software?
MA: Personally, yes. Project level, unknown.
5. Does your project consider applicability for reuse during software development?
MA: Personally, yes. Project level, unknown.
NOTE: The WHY something was done can be as important as WHAT was done.
Do You Know Reuse When You See It?
Models of reuse
Based on lessons learned from previous attempts or detailed analysis.
Reuse of Architecture
Enough detail to generate a product that performs the generalized task. A Basic
Architecture has key concepts, elements, and the organization of elements.
The Reusable Architecture establishes a sound starting point for development.
The Automobile
A large rectangle (body), one engine with drive train to rear axle, four wheels, one
steering wheel, two head lights, and two tail lights.
The Story
Character introduction, crisis, failure, discovery, crisis, success, and so on.
Reuse of Design
Enough detail to generate a product that performs a specified task. The Reusable
Design defines a known proven method of implementation, but can still be modified
to fit a specific need.
A Basic Design includes details of implementation
The Number 2 Pencil
A wooden shell, lead (graphite) insert with point, and optional eraser.
Reuse of Product
The product is used, unmodified, as a component for a larger system.
A Goodyear radial tire for a 16 inch wheel rim.
Each of these areas has a different emphasis of use, but as the project develops,
they tend to morph from one area into the next. An Architecture becomes a Design which
develops into a Product. If Reuse is in the mind of the developers, then partitions
may be established as to where one area of development ends and the next one starts.
Reviews could then be held to determine if there is too much or too little detail in
the Architecture, Design, or Product to be a reusable workproduct.
If it is agreed to that the work-product is reusable, then additional documentation is
generated to guide others on what it is needed to efficiently reuse the work-product.
A current example of this would be the Tailoring Guidelines for a Software Development Plan.
Programs need a Support SPM
The Support SMP provides needed organizational support for small IRAD and Demo
programs that have a software component of a few thousand lines of code. These
developments may have only one or two software engineers supporting a chief engineer
and a systems engineer, but they still need someone to help them organize their software effort.
The Support SPM can help:
Complexity
One of the major demons of software and systems in general is complexity. Its nemeses are
reuse and standardization. Although complexity is normally applied to coding logic, it
is also relavent to naming.
Using descriptive names for variables is good. Using a typedef of a base datatype should
be justified.
(SPELL Checked to here)
Who Should Write Documents?
The short answer to this question is, Everyone, and in most companies, anyone can be
given the responsibility to write the documentation, manuals, guides, and references
for their project. Is it any wonder, then, that documents are about the last thing to
be produced in a project and tend to be one of the biggest annoyances to an engineer?
Options:
a. Find an old document of the type you need to write and cut-n-paste content.
b. Train yourself on all of the documentation tools, company standards, and author guides.
c. Contact the Technical Writer assigned to the project for guidance and assistance.
If option c were available, the productivity level and quality of document work products
would take a quantum step to the plus side. In most cases, though, option a is the normal selection.
Since many companies do not train all of their engineer to be formal documentation writers,
they may hire technical writers, but then only assign them to the most visible tasks
such as proposal writing support or customer contracted deliverable work products. This
can limit their usefulness.
A simple improvement would be to have them reserve from one to four hours a week to
be available to any project that needs technical writing support. Another option would
be to have a general pool of technical writers. This would provide engineers with a
resource that is up-to-date on document processes and procedures, improve document
standardization, and reduce rewrites. It reduces the task for the enginner from
figuring out all of the requirements for the document to fill-in-the-blanks with content.
Technical Writers:
Familiar with the company's authoring and document formatting tools such as Microsoft
Word, PowerPoint, and LaTex.
Knowledgeable about company documentation standards and templates.
Establish the format and organization of the document, but not the contents.
Assists in the presentation of the information by suggesting style and form of the content.
Optimization
"It is easier to optimize working code, than to make optimized code work." -Annonimus