Performance: An attribute or a behavior?

Is performance of a system an attribute or a behavior? I guess the answer to this question depends on the perspective you are considering. Lets take the example of a Nissan Quest Minivan as a system.

According to its data sheet it has a performance of 235 hp @ 5,800 rpm and a 240 lb-ft @ 4,400 rpm. This data could be considered a system attribute at the time of design. These are the performance goals the design engineers are targeting in the product that rolls off the assembly line. One can argue that once the minivan hits the road and a driver presses on the gas pedal these numbers no longer become attributes but rather operational behaviors. As the system ages the numbers would change.

Enterprise Architecture

Enterprise Architecture is the organizing of logic for business processes to reflect the integration requirements of an enterprise's operating model.

It is important to identify the processes, data, technologies and interfaces that are core to the definition of the operating model. Different enterprises will have different operating models and hence the focus on each of those mentioned areas would be different. For example a wholesaler in the oil industry will focus on processes and data more than a retailer in the finance industry whose focus would be on client data and interfaces.

Some artifacts that could be used as starting points to define an enterprise architecture could be functional architectural diagrams, which would highlight the main functional processes. Another artifact is an external interface diagram. A list of shared data and key technologies linking the various applications also serves as a good defining artifact.

Daddy I Want a Cat Now: A Real-Time System Delimma

It was the first week of school when my daughter came back from school and dashed through the door to remind me of the promise I made last school year. I promised her that in the fall we can buy the cat she always wanted. I was faced with a real-time problem. I had to make a decision on the spot to accommodate her request. The 8 year old has been patiently waiting for 3 long months to invite that little creature into our home. Opposed to the idea of having one, I had to delay until she can prove herself responsible to care for little kitty.

So as humans we get faced with real-time problems, and we need to deal with them in intelligent ways to avoid long term damage, and short term devastation. The human real-time system shares some similarities with a real-time software system processing delay-sensitive service requests.

So what are the key attributes of a real-time system? In a nutshell it is a system that must produce accurate computational results and these computations must conclude within a predefined period. These two attributes are known as the functional correctness and timing correctness of the system, and both have equal importance.

Another key aspect of a real-time system is that is has awareness of the environment in which it exists and applications it hosts, hence it is considered deterministic as the responses to service requests are time bound. This deterministic response behavior makes a real-time system less adaptive to changes in the environment. We can easily see the dilemma faced by real-time systems operated in highly dynamic environments. A balance needs to occur between the deterministic response and the adaptiveness of the system.

The same applies to a parent's situation with his/her child, a deterministic response is needed and expected by the child. After waiting all these months for kitty and behaving well during the summer break, the child expects a real-time response. The child will not expect "ok, let me think about it". A decision has to be made on the spot, hence the time boundness. Additionally the parent is aware of the consequences of denying or approving the request. In the former case the child will be devastated and will accuse parent of not holding on to promises, in the latter case kitty will go on hunger as the child is still not responsible enough to care for kitty.

This kitty real-time system involves (1) a service request initiated by the child to own a cat, (2) a decision-maker processor - the parent - and (3) the external environment - the child's attitude. Do the laws of embedded real time systems apply here? They probably do, however it is a lot more complex than a technology real-time system such as a missile defense system and involves psychology, social behavior and various other domains of art. A missile defense system involves a human element in the decision-maker process to fire or not to fire, however the system element expecting the real-time response is not a human, it is a missile launch pad, and its behavior is well understood. In the example of the kitty, the child's behavior to the parent's real-time response is not clearly understood, it could manifest itself in a sudden outburst of tears and crying, an acceptance accompanied with long term dissatisfaction, short term happiness, etc... modeling and predicting human factors is a whole other story...

Common Software System Development Methodologies

There are 4 common software system development methodologies. These methodologies comprise of:

(1) A process - to define activities or tasks to achieve the goal of the methodology
(2) A vocabulary - to describe the process and work products created during the process application.
(3) Rules and guidelines - to define the quality of the process and the work products

The four methodologies are shown in the table below along with their strengths and weaknesses.

Domain	RUP	Shlaer-Mellar	CRC	XP
Emphasis	- Incremental and iteration	- Execution for verification	Scenarios and simplicity	Simplicity, design through integration and refactoring
Strengths	- Comprehensive - Well Defined artifacts and roles - Incremental deliveries	- Simulation capability - Well defined testing rules - Well defined transition from one step in the process to another - Real-time system support	- Simplicity - Easy to use to transition from procedural to object oriented concepts - Focuses on object value, leading to optimized system	- Focuses and cares about the programming environment - Supports and requires close relationship between clients and developers - Accounts for changes in the development process
Weakness	- Large and difficult - Complicated rules - Customization is not straight-forward - Limited vendors supporting the process	- Considerable learning curve - Focuses too much on state modeling. - Limited vendors supporting the process	- Supports primarily classes - Requires a facilitator	- Relies on an ideal development environment - Depends extensively on client commitments - Requires high quality human interaction among development team - The system is in a constant state of maintenance

A System for Innovation

Diversity in our lives brings a wealth of knowledge and experience at unexpected ways. There are many facets to diversity; examples are age diversity, education diversity, background diversity, interest diversity and the list can go on.

Imagine if all people were interested in playing basketball, then all what the world will know is basketball. Now with the presence of soccer, one can think and say, what if we come up with a game that has some attributes of basketball and some of soccer, and call that game handball, just an example. This diversity in the athletic domain can yield new types of games. Not only that, but also consider for a moment how a team can lead innovation based on experiences from basketball as a knowledge domain. There are many areas, team work, flexibility, adaptability, endurance, and probably a dozen other areas of knowledge.

This weekend I had the privilege of hosting a couple of my friends' teens at home. Being a married professional my late 30s, most people I deal with are professionals around my age or a bit older or younger, as well as my spouse and young girls. How often do I interact with a 14 or 16 year old? The answer is not very often. Spending an evening together pondering on the creation of Allah (SWT), and reading from his book, and then hanging out at the gym together the next morning has given me a very interesting insight. "Strong nations need and must communicate across all sections of the society". The old and the young, the senior and the junior, the poor and the rich, and so on ...

This should be no surprise to a systems engineer, as Allah (God) tells us in the Quran that God has created us from a male and female and make us into tribes and nations to know one another and to know that verily the most honorable among you are ones who have the most piety.

يَا أَيُّهَا النَّاسُ إِنَّا خَلَقْنَاكُم مِّن ذَكَرٍ وَأُنثَى وَجَعَلْنَاكُمْ شُعُوبًا وَقَبَائِلَ لِتَعَارَفُوا إِنَّ أَكْرَمَكُمْ عِندَ اللَّهِ أَتْقَاكُمْ إِنَّ اللَّهَ عَلِيمٌ خَبِيرٌ

Allah has created diversity. Diversity in gender - men and women - as well as in color, demographics and place of origin. This diversity if put to action correctly in compliance and adherence to the guidance of Allah, we will not only succeed in this life but also in the hereafter.

On the other hand, we are also diverse in levels of piety and belief. As humans we can recognize this through contrast and comparison to other groups and nations. Someone who is not on the right path can easily identify so by seeing or dealing with someone who obeys his Lord and fears the consequences.

In just less than 30 minutes with two teens, I was able to learn about every single piece of workout equipment in a room the size of about 70' by 40'. In an hour we tried out almost 75% of the equipment. So you probably ask now, whats so interesting about this? What is interesting is the unexpected power of knowledge developed by mixing the teen and the 30 year old ideas, thoughts and passions. My younger friends provided a blend of motivation, risk assumption, willingness to explore and hastiness. I pitched in with risk control, analysis, prioritization and feedback. Now lets consider on the other hand that I went to same gym with the parents of my young friends - i.e. my friends - would we have explored those dozens of equipment? Would we have attempted to try half of what we tried out? Would we have motivated each other and encouraged one another to try out equipment... I can guess probably not. Imagine going with a newly retired friend who is in his 60s .. what experiences can we expect and imagine ?? Probably a lot more that are different from those discussed above, adding even further wealth. Humans need to mix across generations, not only for social purposes but also for strength and growth purposes...

This is definitely a complex topic, involving tens if not hundreds of factors... The main point to take out of this discussion is that "Diversity leads to new experiences, these experiences could be good or bad. In either case the experiences tends to be of large dynamic nature", and we should understand its implications very well to better control it, and leverage it to innovate and grow stronger.

Organize Your System: Architecture versus Framework

Architectures and frameworks are among many other artifacts that could be used for organization. So what is the difference between an architecture and a framework?

Architectures define a unified structure of a system. It is concened with the purpose determination, concept, structure, use and behavior of the system. Architectures could be physical, operational, technical or functional.

Frameworks define the data and information that needs to go into an Architecture. For example a framework will define that a functional architecture will include functions, inputs and outputs of these functional blocks, controls and maybe actors performing these functions.

Common frameworks are DOD Architecture Framework (DODAF), The Open Group Architecture Framework (TOGAF), Federal Enterprise Architecture Framework (FEAF), and they define what needs to be in a C4ISR Architecture, Enterprise Architecture and a Federal Enterprise Architecture respectively.

More to come on this topic soon...

Which Soft Skills Do You Consider the Most Important?

The discussion about soft skills and their significance in engineering fields is getting more attention. Soft skills such as active listening, interpersonal skills, emotional intelligence, conflict resolution, negotiation, and the list goes on... are becoming increasingly important and strategic. Engineers are no longer confined to their cubicles within reams of sheets of drawings and calculations.

Engineers are out in the field discussing needs and capabilities with clients, leading technical meetings, discussing details with suppliers and vendors and communicating with other professionals across the globe using collaboration tools such as instant messaging, IP conferencing and real-time audio and video communications.

Which ones in your opinion are more important than others?

Software Systems: What is Your Type?

Software systems are all around us. In the car, microwave machine, washing machine, traffic lights, bank, Internet, and just about every place we go to. The big question is how different are these software systems from one another?

Some software systems mission is to store data so other systems can retrieve it and process it. The Internet and a complex database cluster system are two examples. Other systems process data and provide results such as credit card processing systems and airline reservation systems. A third software system is one embedded in some control logic on an appliance like a microwave program or washing machine, and the list goes on...

We have heard of the terms pervasive computing and pervasive networking. They refer to distributed computing elements connected via a complex communication network allowing tight integration into our lives. An example would be a network of sensors communicating with one another and a number of management nodes.

Can we define a new type of software system called the pervasive software system? One which is deployed on a large number of computational devices across a complex network, each device performing a custom computational task - dependent on the devices location and mission, which could be time dependent - and sending the results to a larger "master" computer.

Note the difference between the pervasive computing and pervasive software is that in a pervasive computing environment the various nodes are dispersed, but each has a fixed computing configuration - fixed hardware and software. The pervasive software system on the other hand is a software system broken into pieces each running remotely on its own pervasive computer, and these software pieces could be reconfigurable and dynamic according to where the pervasive computer is and what its mission at a particular point in time is ...

Technical Arguments

In order for a systems engineer to come up with a decision, there has to be a solid argument. Arguments are not conflicts, but rather expressions of ideas with evidence and facts. Arguments should be verifiable and are not based on emotions.

I am teaching a debate class for middle schoolers this weekend. So what is the link between that and this blog. Well, everyone needs to debate. Debate is not just for politicians, attorneys and TV host shows. Engineers need to debate technical ideas, requirements and design constraints. the systems engineer needs to ensure that technical arguments are backed up by solid facts. These facts need to be verifiable, just like requirements.

Teaching engineers how to debate is as important as teaching attorneys how to present a case in court. Dealing effectively with complicated and complex systems requires no only engineering and science, but also art in the form of architecture, soft skills and critical thinking.

Decision Making and Systems Engineering

Systems engineering is an interdisiplinary approach to enable the successful realization of systems. Learning the systems engineering process is not a complex task. The tough part of systems engineering is making decisions related to trade-off studies, and balancing among the different requirements, which could at many times be orthogonal and conflicting.

An effective systems engineer is one who can provide insights and advice related to technical decisions. This would occur as follows,

1. Ensuring requirements are clear, well understood, correctly prioritized, and motivation well understood
2. Modeling and simulation and developing what-if scenarios
3. Conducting trade studies and parametric analysis
4. Clearly defining interfaces and boundaries, their requirements and impacts
5. Comprehensive risk management and optimum risk handling
6. Justify changes to requirements, design, scope, resource demands and technology
7. System optimization to develop a best solution in situation where multiple aspects of a system can be optimized
8. clearly defining dependencies, integration constraints and alternatives

The value of the system engineer is not only implementing the systems engineering capability pattern, but also ensuring that true value is being realized through the implementation of the SE capability patten. This true value will be achieved through solid decision-making.

A World of Decisions

Very often we get challenged to make decisions on problems which have more than one criteria. This decision making process is referred to as "Multi-Criteria Decision Making (MCDM)".

MCDM defines two major classes for determining optimal decisions. The first known as Multi-Objective Decision Making (MODM), and the second Multi-Attribute Decision Making (MADM). Both classes could support single or multiple decision makers as well as multiple data types -deterministic, stochastic, or fuzzy.

MODM deals with problems in which the decision space is continuous. MADM on the other hand is used when solutions are discrete.

The key point in making decisions is not what one is deciding, but rather how the decision is made. The ability to make sound decisions is a fundamental life skill, each one of us experiences everyday.

To read further:
1. Tryantaphyllou, Shu, Sanchez, and Ray, "Multi-Criteria Decision Making: An Operations Research Approach", Encylopedia of Electrical and Electronics Engineering, John Wiley, 1998, pp. 175-186.

2. Hammond, Keeney, Raiffa, "Smart Choices: A Practical Guide to Making Better Life Decisions", Broadway Books, 2002

Squeezing the Last Bit out of a Technical Review

Often times on projects with extremely tight schedules and very short durations, the project team does not have the time to document kep aspects of a system. For example external interface specification may not be documented in the form of an Interface Configuration Document. However the designer might have opened change requests/engineering changes and documented what the impact on the interface would be. This practice could lead to missing some requirements, or not looking into all interface design issues.

In situations such as the above (you have a 4 week project to develop a large system, no time or resources to develop a true "ICD") the system engineer feel helpless. One key authority the system engineer has is to use the critical design review to gather these requirements which are all over the place. For example, using the ICD example above, the SE can ask questions like, 'What impact will this CR have on the external interfaces?", or "What test requirements are needed to verify this CR". Capturing this information into a table, the SE can then later reverse engineer a systems interface requirement document, or an ICD.

Technical / Scientific Reviews Leadership

We had a guest speaker come in from Johns Hopkins APL to our leadership class at UMBC last night. He shared with us his career experiences and some tips.

One thought I got from his visit was the importance of teaching technical/scientific review meetings leadership. I did a search on the Internet quickly to see what is out there, but there is very little literature in how to successfully run and conduct a technical review.

I am not talking from a process perspective, like what the process for an SRR should be. These processes are well known and understood. But rather I am talking from the leadership perspective. Areas like

1. Tools
- What are the best tools to use during the review, slideware, spreadsheets, technical documents, etc..
- Can reviews be conducted remotely over collaboration S/W like NetMeeting, Notes
- What is more effective in-person or remote meetings? I did both each has it pros and cons

2. Negotiation schemes
- So the client PM takes over the meeting, how do you as the lead SE on the contractor side react?
- Just got into a project yesterday, you need to do a walk-thru tomorrow, who are players? how to run the review smoothly?

3. Time control
- Mr. chatter loves to chat, and whiner complains about each requirement, and repeater has to make sure we all memorize his statements before we leave, how to filter and weed out the garbage talk and retain the technical meat you are looking for?
- One big 8 hr meeting with 1 hr lunch and 2 15-min breaks, or 4 2-hr meetings over 4 days?

4. Scope control
- Ok, we are doing a use case review, but lets quickly go over the architecture, 60/40 opposition, what do you do?

I attended a workshop by Edward Tufte, the professor at Yale last Spring, he discussed some very interesting thoughts about how some organizations fail to conduct reviews simply because they use poor tools. He gave the example of NASA and the shuttle explosion. In his opinion as well as the many experts who evaluated the crash, the failure in the shuttle started not at launch, but rather way back in the technical review process. NASA was too heavily dependent on power point fluff. It was very easy to lose focus of the strategic technical issues and questions during the reviews.

This all needs more research...

Have You Looked at the 2 F Words? Five Factors !

Developing a new product in no easy job. The uncertainity that looms around you seems endless. This uncertainity can be broken down into 5 areas as explained by Michael Porter, in his book "Competitive Advantage: Creating and Sustaining Superior Performance".

1. Potential entrants

2. Supplier Power

3. Buyer Power

4. Substitutes

5. Industry competitors

New Product Requirements

There are various sources for requirements gathering for a product or service. Obviously the most important source is the customer who will be using the product or service.

Another valuable source is the environment in which the product and customer will both be surrounded by. A list of the most relevant environments that a product manager or systems engineer should take a look at are:

1. Technological Environment
Presence of new inventions, innovation, methods, processes, materials to achieve new tasks or perform older one better, etc...

2. Economic Environment
The cyclical changes in local and global economies, inflation (prices rising/lower purchase power), recession (trade down/employment down), unemployment, depression (panic), recovery, prosperity (employment up/trade up), off-shoring, debt/savings levels, income distribution

3. Competitive Environment
The landscape of competing (monopoly, perfect, oligopoly, monopolistic), competitors status, etc...

4. Sociological Environment
Cultures, changes in industries, religion, subcultures (teens, seniors), crime rates, etc...

5. Political-Legal Environment
Legislation, regulations, PACs, wars, etc...

6. Demographic Environment
Age, gender, customs, location of residence, etc...

7. Natural Environment
Natural resources, raw materials, pollution, etc...

Astute system engineers should research all these environments. The level of research might differ from on environment area to another depending on the product/service being developed. In some cases other environments might be considered and some of those listed above ignored.

Needs - Wants - Demands

Just like a smart marketer, an astute systems engineer knows the difference between the three:

Needs - are basic requirements, like eating and going to the bathroom

Wants - are needs that become requirements for fulfilling basic needs, for example people want education to find a job, to make money to buy food to meet the basic need. Wants are shaped by the environment the client is in.

Demands are wants for specific products coupled with an ability to pay.

Marketers do not create needs. Needs already exist. People need to eat, move, dress and learn. Marketers only promote the idea that a burger, car, Jeans and private school will satisfy the client's needs, by highlighting the benefits the client will achieve using the product.

Is that What Your Client Really Needs?

Customers need a lot of things, in most cases they do not realize what they need. However we can usually group a customer's need into these 5 areas:

1. A stated need - I need a box of cereal
2. Real need - I need something healthy to eat quickly in the morning
3. Unstated need - I expect to find the cereal box easily and quickly
4. Delight need - If the cereal will allow me to add fresh raisens and banannas all the better
5. Secret need - Got to show off infront of my wife and tell her I got it on sale 3 for price of 1

An experienced system engineer can sense and identify the needs 2 - 5, and bring them out to the client for verification -- this is where value is added.

The 4 Ps of Marketing and 13 Aspects of a Good Requirement

Just as marketing has 4 Ps: Product, Promotion, Place and Price

Requirements have 13 attributes:
1. Describe what and not how
2. Atomic
3. Unique
4. Documented
5. Identifies owner
6. Traceable
7. Necessary
8. Complete
9. Unambiguous
10. Identifies applicable states
11. Testable and quantitative
12. Not a constraint
13. Not a goal

Rule of thumb: A requirement should be satisfied by only 1 design component, it not feasible then it should be broken down further.

Systems Engineers Don't Only Engineer Technology Systems

That is true... Almost all industries and discplines need system engineers, simply due to the fact that everyone needs something.

Traditionally we are used to seeing systems engineers working in the defense sector to define requirements for the next state-of-the-art missle, or at a high-tech firm developing and trackign requirements for the seemless e-commerce application.

Masjids, churches and synagouges need system engineers to articulate the needs of their congregations, define priorities and ensure that requirements add value. Schools need to develop effiecient operational systems, retail stores need to streamline their sales, and the list goes on...

Just like the following list of items could be marketed.. they could also be system engineered...

Goods - Technology products, consumer products, commercial products, etc...

Services - B2B, B2C, C2C (yeah myspace, blogs, etc..), C2B (resume websites, etc..), professional, educational, security, etc... the list services never ends

Events - Yes events which are complex could require the art of engineering

Experiences - Ever heard of Opera Aida..

Persons - We can market persons, can we system engineer a person.. sure we can define requirements for that person to reach certain goals.. we call that also coaching, mentoring, training, and many other things ...

Places - Engineer a downtown...

Properties - Engineer the Pyramids

Organizations - Build a non-profit systematically.. yes that also is systems engineering

Information - Indeed.. that is what we call IT system engineers...

Ideas - System engineers make not only great inventors because of their holistic views and ability to identify gaps, but also.. great value initiators .. very similiar to marketing slogans..

"Everyone can benefit from a little System Engineering"
Ayman Nassar

Ways for Satisfying Needs and Wants

One of my teachers, Prof. Pitta, of University of Baltimore once mentioned There are 4 main ways people can achieve their needs, let take a look as well as at their (Acquirer / Releaser) score.

Coercion:
When someone takes something like force. Like someone breaking into your car to steal your GPS. In this case, that someone achieve a small gain, he probably sells that $600 GPS for $50 or for a couple of sniffs of white powder. The victim, you, loses, the cost of repairing the car glass, replacing the GPS and the sense of security. Score: (+ / ----)


Origination:
When one goes out to acquire a product or service through exerting effort, using natural and free resources. This is like going fishing, spending a whole day under the sizzling sun, and getting a catch of a dozen trouts. You win, no one loses (at least directly). Score (++ / neutral)

Transfer:
When someone receives a product or service as a gift. In this case no productivity is performed and hence not mutual exchange of value. Such is the case with giving a begger change. The begger gains a limited value, but the donor doesn't gain, besides the fact of maybe feeling good about helping someone in need, nor does the society. Please do not confuse begging with charity. Charity is used for productivity and development. Score (+ / +).

Exchange:
This is where value lies. Exchange is when you go a get a car in

exchange of 20 g rand, or an iPod for $200, or a voice recorder for $2 5. In these cases, you will use the car to go to work (get income, take kids to school, etc..) so you develop value out of the car, or use the iPod to listen to Quran to be a good person (gaining value for yourself long term as well as short term and society), and recor d lectures or interviews on your voice recorder. In all these c ases you gained value from the products you acquired, the seller gained value by receiving cash and making profit on his/her sale and invested the extra towards further production and development. True value occurs in exchanges. Score ( +++++ / +++++)

Marketing and Systems Engineering

Of course there is a great deal of relationship between Marketing and Systems Engineering. After all their main focus is creating and delivering value to cusotmers. The American Marketing Assocation (AMA) defines marketing as "An organizational function and set of processes for creating, communicating and delivering value to customers and for managing customer relationships in ways that benefit the organization and its stake holders.

Marketing is about exchanging products and services to satisfy needs and wants. These needs and wants represent value to those taking part in the exchange process.

Systems engineering is about articulating these needs and wants, representing them clearly and making sure processes exist to deliver these needs and wants "requirements" to the client with low risk.

Everyone is marketing something, whether it is oneself at a job interview, a product they develop, a school they send their children to, a doctor they visit, or a place they travel to enjoy. Sharing the experience of all these types of activities is one way of communicating their value, i.e. marketing ...

What is Simulation?

Simulation is the process of imitation or enactment of a system, process, service or some other action or entity. To perform a good simulation the system engineer needs to have a good understanding of the system being simulated, hence the need for a representitive model. Assumptions and approximations used in the model defintion need to be documented and understood.

We normally conduct a simulation to forecast or analyze how some characteristic of a system will behave in the context of the model developed.

The models used could be classified into different types, common classifications are,

1. Stochastic models / Deterministic models
2. Continuous / Discrete
3. Steady-state / Dynamic
4. Local /Distributed

Commonly used models are the stochastic models. They focus on either studying the effect of time (for example the case of a stock market behaviour) or studying the effect of some random variable (for example random terrain).

A System for Mankind

http://www.youtube.com/watch?v=jn_XvMstTiQ

Workshop Attendees: Questions / Comments

Please post questions, comments or feedback related to the topics covered in the workshop here. Please do not include any personal information, all comments are publicly accessed.

No Silver Bullet for Software - Is that Still True?

It was in the year 1987 when Frederick Brooks wrote his paper "No Silver Bullet: Essence and Accidents of Software Engineering" [1]. In this paper Brooks shared with the software development industry his view of the issues and challenges related to software development. Brooks stated that "Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any", Brooks also stated that the difficulties of software are broken down into two types, the first "essence" are difficulties inherent in the nature of software such as complexity, conformity, changeability and invisibility; and the second "accidents" are difficulties that today attend its production but are not inherent. Furthermore Brooks believed that "the hard part of building software is the specification, design and testing of this conceptual construct (referring to software), and not the labor of representing it and testing the fidelity of the representation".

Are Brooks' thoughts in 1987 still valid and true? This is what this write-up is trying to explore. While I agree with many of the points that Brooks' shares in his paper, I have a different opinion on some of the assumptions he made.

1. Brooks' sees that the issue with software development is not that it is too slow, but rather that hardware progress is too fast. I do not think we can generalize this statement, as a matter of fact a higher performing hardware will be more capable of running an older software much easier and with higher performance than an older hardware technology. We should expect that running Windows 95 on a Pentium 4 processor with 2GB of RAM will be much more efficient and effective than running it on a Pentium I processor with 64MB of RAM. It is true that Windows 95 will not be able to leverage all the benefits of the improved hardware, and to modify it to be able to do so will take probably more time than to move from a Pentium I processor development to a Pentium 4 processor development, this will impact the quality of the modified Windows 95 software, but not the original Windows 95. Taking into consideration the principle of system dynamics that a system's structure - and not the environment in which it is in - dictates its behavior [z2], the real issue lies neither in the slowness of software development nor the higher pace of hardware development, but rather in the structure and architecture of the developed software. It is developed in a way that allows fast, modular and low-error development, the newer release will be out on the market quicker and more will be more reliable. I see the main issue here is not that hardware development is orders of magnitude faster than software which is true, but rather that processes and methods used for software development are not mature and solid enough as those used in hardware development projects.

2. Brooks also mentions that computers have very large number of states and that this makes conceiving, describing and testing computers hard. This is another example of where a well-defined scalable process for state verification and behavior checking at these different states would solve the issue. Having many states does not add complexity, it only adds time demands and repetitive testing under different states, a task that should be easily achieved by a machine or computer. Brooks mixed between complexity and complication, software state definition might be time-consuming, complicated and repetitive, however the behavior of the application should be easily understood in a state given the various inputs and constraints. I do agree with Brooks that a larger number of elements in a software application will lead to a large level of interaction and that the results will most probably not be linear, and we can agree that the relationship between the whole and the elements is not linear and could very well be complicated as well as complex.

3. Since Brooks assumed that software applications are complex he assumed that communications among team members, program states, functions and structure are all complex. As mentioned earlier I believe they are not complex but rather complicated. If we use a part-to-whole, or bottom-up approach in architectural design we should be able to understand the program state, functions and capabilities at a lower level and as we add more capabilities we should map back to the original needs and be able to determine what the overall system would look like, and how it will behave, this might be a complicated process, but is should not be complex. If it were complex, that mans that somewhere in our design and development processes we lost track of what we are building and how it will behave, this requires a pause and revisit of the methods utilized, just like any other engineering discipline will do, to continue the engineering activity not fully aware of what has been achieved and how it maps to the stake-holder needs is poor and foolish engineering practice and is not an attribute of the engineering artifact being developed. To make an analogy a civil engineer designing a concrete mix for a skyscraper should know what the characteristics and behavior of the mix is expected to be, if there is a behavior that is unknown to the engineer in a particular state, say for example, at temperatures above 105F, proper engineering sense calls to pause, and do some analysis to find if the mix is still valid, or a redesign is needed, this same concept should apply to software development.If we are to assume that software implementation is complex, then yes, it will lead to difficulty of communication among team members, this is due to the fact a complex behavior means that the behavior of the software as a whole is not understood analyzing the parts of the software and hence team leads will not be sure which team members of the implementation to include in a communication. This difficulty of communication depends on several key factors, the number of team members, the tools, processes, standards and methods used for communication. Communication difficulty is common across any project team with large number of participants or on a project with poor communication planning.The difficulty mentioned in enumerating all the possible states of a program is also another weak point. With advanced tools and databases we can analyze the program behavior and document these findings along with state information in a database, which will make the management and retrieval of state information much more efficient and easier. Brooks has not illustrated how does complexity of function increase the difficulty in invoking function. Invoking function is dependent on user interfaces and program structure, and hence we can not assume that a more complex function will lead to a difficult access of such function. Today with the presence of patterns and contained components we feel that this becomes less of an issue from the days of Brooks.

4. Changeability is common in all technology areas today, rate of changes in non-IT technology areas might be less, but still high compared to other industries and segments. The issues of changeability is not a SW inherent problem, but rather a management issue. Brooks states in his paper that “SW can be changed more easily”. This is not true, what is true is the perception that SW changes can be easily implemented. Because SW is intangible and no fixed tangible assets are easily identified, managers and clients tend to not realize that SW just like any other area of technology requires a careful change management process. An airplane with 30 million parts on it could be much more complex when it comes to making changes. However because of all the steps that must be performed to perform the change; ranging from prerequistes for safety, reliability, regulation conformance and much more the cost of change is high and can not be negotiated. In the case of SW, a different peception is applied where we can do an easy change without impacting too many other areas, this claim is simply not true and could lead to the same disastrous effects of changes on an airplane, air traffic controller system, subway control system or stock exchange.

5. The argument that SW is invisible and “unvisualizable” by Brooks is not a strong one. Various methods of scenario representation, data flow, dependency patterns, time dependence could be implemented to improve the understanding and visualization of a software application process. What should be visualized is a business process, not the SW application, the SW application should be represented in a logical form as a tangible product comprised of smaller logical components. there are plenty of innovative methods of representing business processes and information thanks to the world of frameworks !

[1] F. Brooks, "No Silver Bullet: Essence and Accidents of Software Engineering", Computer, Vol. 20, No. 4 (April 1987) pp.10-19.

[2] J. Sterman, "Business Dynamics: Systems Thinking and Modeling for a Complex World", Irwin McGraw-Hill, 2000, pp. 28.

Do we Call This a Trade Study?

How far and risky can a trade study decision go?

Take a look at this video from Yahoo


It is not common that systems engineers need to make an instant decision on a trade analysis. However in some situations during operational phases of a system instant decisions might need to be made. Are current trade study methods adequate for instant decision-making?

Data Modeling

Data modeling is concerned with 3 main items,

1. Entities - which exist in a system
2. Attributes - characteristics and facts about subsystems and components of a system
3. Relationships - rules for co-existence and operations between components and subsystems of a system.

Entities could be described by using block diagrams, boundary diagrams, or a list of compnents and subsystems. An entitiy name should be in singular for example receipt , not receipts.

Relationships are illustrated by using lines to show cardinality and optionality. Numbers could be wrriten at each end of the line. Examples are

1:1 = one-to-one, a plane can have one pilot
1:1+ = one-to-one or more, a client has one or more purchase requisitions
1:0+ =one-to-none or more, a purchase requisition which has no line items or more
1:m = one-to-many, a teacher has many students
m:n = many-to-many, a teacher has many students, and students can have many teachers