Overview to System Simulation Tools

System simulation tools provide the software engineer with the ability to predict the behavior of a real-time system prior to the time that it is built. In addition, these tools enable the software engineer to develop mock-ups of the real-time system, allowing the customer to gain insight into the function, operation, and response prior to actual implementation.
Tools in this category allow a team to define the elements of a computer-based system and then execute a variety of simulations to better understand the operating characteristics and overall performance of the system. Two broad categories of system simulation tools exist :
- General purpose tools that can model virtually any computer-based system.
- Special purpose tools that are designed to address a specific application domain.

REPRESENTATIVE TOOLS :
- CSIM : Developed by Lockheed Martin Advanced Technology labs, is a general purpose discrete-event simulator for block diagram-oriented systems.
- Simics : Developed by Virtutech, is a system simulation platform that can model and analyze both hardware and software-based systems.
- SIX : Developed by Wolverine Software, provides general purpose building blocks for modeling the performance of a wide variety of systems.

Introduction to System Simulation

Systems simulation is a set of techniques for using computers to imitate, or simulate, the operations of various kinds of real-world facilities or processes.The computer is used to generate a numerical model of reality for the purposes of describing complex interaction among components of a system. The complexity of the system surges from the stochastic (probabilistic) nature of the events, from the rules for the interactions of the elements, and the difficulty to perceive the behavior of the systems as a whole with the passing of time.

When to use simulations?
Systems that change with time, such as a gas station where cars come and go (called dynamic systems) and involve randomness.Modeling complex dynamic systems theoretically need too many simplifications and the emerging models may not be therefore valid. Simulation does not require that many simplifying assumptions, making it the only tool even in absence of randomness.

System terminology:
- State: A variable characterizing an attribute in the system.
- Event: An occurrence at a point in time which may change the state of the system.
- Entity: An object that passes through the system.
- Queue: It is a task list.
- Creating: Creating is causing an arrival of a new entity to the system at some point in time.
- Scheduling: Scheduling is the act of assigning a new future event to an existing entity.
- Random variable: A random variable is a quantity that is uncertain.
- Random variate: A random variate is an artificially generated random variable.
- Distribution: A distribution is the mathematical law which governs the probabilistic features of a random variable.

Introduction to System Modeling

A model is a simplified representation of a system at some particular point in time or space intended to promote understanding of the real system. A system is understood to be an entity which maintains its existence through the interaction of its parts. A model is a simplified representation of the actual system intended to promote understanding. Whether a model is a good model or not depends on the extent to which it promotes understanding. Since all models are simplifications of reality there is always a trade-off as to what level of detail is included in the model. If too little detail is included in the model one runs the risk of missing relevant interactions and the resultant model does not promote understanding. If too much detail is included in the model the model may become overly complicated and actually preclude the development of understanding.

System modeling shows how the system should be working. To construct a system model, the system engineer should consider the following factors :
- Assumptions : It reduces the number of possible permutations and variations, thus enabling a model to reflect the problem in a reasonable manner.
- Simplifications : It enable the model to be created in a timely manner.
- Limitations : It helps to bound the system.
- Constraints : It will guide the manner in which the model is created and the approach taken when the model is implemented.
- Preferences : It indicates the preferred architecture for all data, functions, and technology. The preferred solution sometimes comes into conflict with other restraining factors.yet, customer satisfaction is often predicated on the degree to which the preferred approach is realized.

Planning Practices - Type of Software Engineering Practice

The planning activity encompasses a set of management and technical practices that enable the software team to define a road maps it travels toward its strategic goal and tactical objectives. There are many different planning philosophies. Regardless of the rigor with which planning is conducted,the following principles always apply :

- Understand the scope of the project.
- Involve the customer in the planning activity.
- Recognize that planning is iterative.
- Estimate based on what you know.
- Consider risk as you define the plan.
- Be realistic.
- Adjust granularity as you define the plan.
- Define how you intend to ensure quality.
- Describe how you intend to accommodate change.
- Track the plan frequently and make adjustments as required.

What questions must be asked and answered to develop a realistic project plan ?
- Why is the system being developed ?
- What will be done ?
- When will it be accomplished ?
- Who is responsible for a function ?
- Where are they organizationally located ?
- How will the job be done technically and managerially ?
- How much of each resource is needed ?

Communication Practices - Type of Software Engineering Practice

Before customer requirements can be analyzed, modeled, or specified they must be gathered through a communication activity. Effective communication is among the most challenging activities that confront a software engineer. However, many of the principles apply equally to all forms of communication that occur within a software project.
Software engineers communicate with many stakeholders, but customers and end users
have the most significant impact on the technical work that follows. In some cases the customer and the end user are one in the same, but for many projects, the customer and the end user are different people, working for different managers in different business organizations.

- Listen : Try to focus on the speaker's words, rather than formulating your response to those words.
- Prepare before you communicate.
- Someone should facilitate the activity.
- Face-to-face communication is best.
- Take notes and document decisions.
- Strive for collaboration.
- Stay focused, modularize your discussion.
- If something is unclear, draw a picture.
- Once you agree to something, move on.
- If you can't agree to something, move on.
- If a feature or function is unclear and cannot be clarified at the moment, move on.
- Negotiation is not a contest or a game. It works best when both parties win.

Introduction to Software Engineering Practice Cont...

Construction incorporates a coding and testing cycle in which source code for a component is generated and tested to uncover errors. Integration combines individual components and involves a series of tests that focus on overall function and local interfacing issues.
Coding principles define generic actions that should occur before code is written, while it is being created, and after it has been completed. Although there are many testing principles, only one is dominant : testing is a process of executing a program with the intent of finding an error.
During evolutionary software development, deployment happens for each software increment that is presented to the customer. Key principles for delivery consider managing customer expectations and providing the customer with appropriate support information for the software. Support demands advance preparations. Feedback allows the customer to suggest changes that have business value and provide the developer with input for the next iterative software engineering cycle.

Introduction to Software Engineering Practice

Software engineering practice encompasses concepts, principles, methods, and tools that software engineers apply throughout the software process. Every software engineering project is different, yet a set of generic principles and tasks apply to each process framework activity regardless of the project or the product.
A set of technical and management essentials are necessary if good software engineering practice is to be conducted. Technical essentials include the need to understand requirements and prototype areas of uncertainty, and the need to explicitly define software architecture and plan component integration. Management essentials include the need to define priorities and define a realistic schedule that reflects them, the need to actively manage risk, and the need to define appropriate project control measures for quality and change.
Customer communication principles focus on the need to reduce noise and improve bandwidth as the conversation between developer and customer progresses. Both parties must collaborate for the best communication to occur.
Planning principles all focus on guidelines for constructing the best map for the journey to a completed system or product. The plan may be designed solely for a single software increment, or it may be defined for the entire project. Regardless, it must address what will be done, who will do it, and when the work will be completed.
Modeling encompasses both analysis and design, describing representations of the software that progressively become more detailed. The intent of the models is to solidify understanding of the work to be done and to provide technical guidance to those who will implement the software.

Introduction to Feature Driven Development (FDD) - Type of Agile Software Development

Feature Driven Development (FDD)was originally developed and articulated by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results. FDD designs the rest of the development process around feature delivery using the following eight practices:

1. Domain Object Modeling
2. Developing by Feature
3. Component/Class Ownership
4. Feature Teams
5. Inspections
6. Configuration Management
7. Regular Builds
8. Visibility of progress and results

Feature Driven Development asserts that:
- A system for building systems is necessary in order to scale to larger projects.
- A simple, but well-define process will work best.
- Process steps should be logical and their worth immediately obvious to each team member.
- "Process pride" can keep the real work from happening.
- Good processes move to the background so team members can focus on results.
- Short, iterative, feature-driven life cycles are best.

FDD recommends specific programmer practices such as "Regular Builds" and "Component/Class Ownership". FDD's proponents claim that it scales more straightforwardly than other approaches, and is better suited to larger teams. Unlike other Agile approaches, FDD describes specific, very short phases of work which are to be accomplished separately per feature. These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.

Quick Overview of Crystal Methods - Type of Agile Software Development

The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics.

The use of the word "crystal" refers to the various facets of a gemstone — each a different face on an underlying core. The underlying core represents values and principles, while each facet represents a specific set of elements such as techniques, roles, tools, and standards. Cockburn also differentiates between methodology, techniques, and policies. A methodology is a set of elements (practices, tools); techniques are skill areas such as developing use cases; and policies dictate organizational "musts".

Introduction To Scrum - Type of Agile Software Development

Scrum is an agile method for project management developed by Ken Schwaber. Its goal is to dramatically improve productivity in teams previously paralyzed by heavier, process-laden methodologies. Its intended use is for management of software development projects as well as a wrapper to other software development methodologies such as Extreme Programming.Scrum is a lightweight management framework with broad applicability for managing and controlling iterative and incremental projects of all types. With Scrum, projects progress via a series of iterations called sprints. Each sprint is typically 2-4 weeks long. Scrum is ideally suited for projects with rapidly changing or highly emergent requirements.

A scrum team is typically made up of between five and nine people, but Scrum projects can easily scale into the hundreds. The team does not include any of the traditional software engineering roles such as programmer, designer, tester, or architect.
- The product owner is the project’s key stakeholder and represents users, customers and others in the process.
- The ScrumMaster is responsible for making sure the team is as productive as possible.
- The product backlog is a prioritized features list containing every desired feature or change to the product.
- At the start of each sprint, a sprint planning meeting is held during which the product owner prioritizes the product backlog, and the scrum team selects the work they can complete during the coming sprint. That work is then moved from the product backlog to the sprint backlog, which is the list of tasks needed to complete the product backlog items the team has committed to complete in the sprint.
- Each day during the sprint, a brief meeting called the daily scrum is conducted. This meeting helps set the context for each day’s work and helps the team stay on track.
- At the end of each sprint, the team demonstrates the completed functionality at a sprint review meeting, during which, the team shows what they accomplished during the sprint.

Scrum enables the creation of self-organizing teams by encouraging verbal communication across all team members and across all disciplines that are involved in the project. A key principle of scrum is its recognition that fundamentally empirical challenges cannot be addressed successfully in a traditional "process control" manner.

Dynamic Systems Development Model (DSDM) - Type of Agile Methodology

The Dynamic Systems Development Model was developed in the U.K. in the mid-1990s. DSDM favors the philosophy that nothing is built perfectly the first time and looks to software development as an exploratory endeavor.

The nine principles of DSDM are:
- Active user involvement.
- Empowered teams that the authority to can make decisions.
- A focus on frequent delivery of products.
- Using fitness for business purpose as the essential criterion for acceptance of deliverables.
- Iterative and incremental development to ensure convergence on an accurate business solution.
- Reversible changes during development.
- Requirements that are baselined at a high level.
- Integrated testing throughout the life cycle.
- Collaboration and cooperation between all stakeholders.

Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using MoSCoW Rules:
M – Must have requirements
S – Should have if at all possible
C – Could have but not critical
W - Won’t have this time, but potentially later
All critical work must be completed in a DSDM project. It is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that if necessary, they can be removed to keep from impacting higher priority requirements on the schedule.
The DSDM project framework is independent of, and can be implemented in conjunction with, other iterative methodologies such as Extreme Programming and the Rational Unified Process.

FTP Software & Anonymous FTP Servers

FTP Software
Depending on what you are planning to do with your FTP software you should pick different ones. There are hundreds of free pieces of software so there is a very good choice. The three software packages are:

- Cute FTP : It used to be the best shareware FTP program around. It is easy to use and has many functions. Unfortunately, because it has become so popular, the latest version only allows you to transfer one file at a time unless you register. If you can find a copy of version 2.6.* it is an excellent program.

- FTP Explorer : It is not such a good program as Cute FTP but it is freeware so there are no annoying nag-screens. It can be downloaded here.

- Elite FTP : It is not such a good program for uploading standard files it works better if you are working with CGI as you can send commands to the server by typing them in.

Anonymous FTP Servers
A host that provides an FTP service may additionally provide anonymous FTP access. Users typically login to the service with an 'anonymous' account when prompted for user name. Although users are commonly asked to send their email address in lieu of a password, little to no verification is actually performed on the supplied data.
The login id for the public accounts on most anonymous FTP servers is anonymous, and guest is also common. The password can be anything, but most anonymous FTP service machines will ask you to enter your complete email address as your password.

Overview Of File Transfer Protocol

File Transfer Protocol (FTP) is a standard network protocol used to exchange and manipulate files over a TCP/IP based network, such as the Internet. FTP is built on a client-server architecture and utilizes separate control and data connections between the client and server applications.

The objectives of FTP are :
* To promote sharing of files (computer programs and/or data).
* To encourage indirect or implicit use of remote computers.
* To shield a user from variations in file storage systems among different hosts.
* To transfer data reliably, and efficiently.

What FTP does ?
It works by establishing a connection between one computer (for example, your PC) and another (for example, your Web server). To do this, you need to know the host name (e.g."webserver.example.com") or IP address (e.g. "12.34.56.78") of your Web server. Your FTP program will allow you to enter lots of different servers if you want (by host name or IP address), and usually you can double-click on one of them to connect to it.
- Logging in
Once connected, the Web server usually asks you for your user name and password.
- Transferring files
You're then logged in to your Web server. Once you're logged in, you can start moving files about. On most FTP programs, this works a lot like Windows Explorer or other similar file managers.
- The home directory
When you first log in, you will be viewing your home directory on your Web server. This will be the directory that contains your website, amongst other files.
- Going dotty
Some FTP programs will show two extra entries in the folder display - a single dot and a pair of dots. The single dot means "this directory" and usually does nothing, but the pair of dots mean "the directory above".

Critical Path Method (CPM)

The Critical Path Method (CPM) is one of several related techniques for doing project planning. CPM is for projects that are made up of a number of individual "activities." If some of the activities require other activities to finish before they can start, then the project becomes a complex web of activities.

CPM provides the following benefits:
* Provides a graphical view of the project.
* Predicts the time required to complete the project.
* Shows which activities are critical to maintaining the schedule and which are not.
CPM models the activities and events of a project as a network. Activities are depicted as nodes on the network and events that signify the beginning or ending of activities are depicted as arcs or lines between the nodes.

STEPS IN CPM PROJECT PLANNING:
1. Specify the individual activities : From the work breakdown structure, a listing can be made of all the activities in the project. This listing can be used as the basis for adding sequence and duration information in later steps.
2. Determine the sequence of those activities : Some activities are dependent on the completion of others. A listing of the immediate predecessors of each activity is useful for constructing the CPM network diagram.
3. Draw a network diagram : Once the activities and their sequencing have been defined, the CPM diagram can be drawn. CPM originally was developed as an activity on node (AON) network, but some project planners prefer to specify the activities on the arcs.
4. Estimate the completion time for each activity : The time required to complete each activity can be estimated using past experience or the estimates of knowledgeable persons. CPM is a deterministic model that does not take into account variation in the completion time, so only one number is used for an activity's time estimate.
5. Identify the critical path : The critical path can be identified by determining the following four parameters for each activity:
* ES - earliest start time.
* EF - earliest finish time.
* LF - latest finish time.
* LS - latest start time.
6. Update the CPM diagram as the project progresses : As the project progresses, the actual task completion times will be known and the network diagram can be updated to include this information. A new critical path may emerge, and structural changes may be made in the network if project requirements change.

CPM LIMITATIONS :
CPM was developed for complex but fairly routine projects with minimal uncertainty in the project completion times. For less routine projects there is more uncertainty in the completion times, and this uncertainty limits the usefulness of the deterministic CPM model.

Program Evaluation and Review Technique (PERT)

Complex projects require a series of activities, some of which must be performed sequentially and others that can be performed in parallel with other activities. This collection of series and parallel tasks can be modeled as a network. The Program Evaluation and Review Technique (PERT) is a network model that allows for randomness in activity completion times.
In a project, an activity is a task that must be performed and an event is a milestone marking the completion of one or more activities. Before an activity can begin, all of its predecessor activities must be completed. Project network models represent activities and milestones by arcs and nodes. PERT originally was an activity on arc network, in which the activities are represented on the lines and milestones on the nodes. Over time, some people began to use PERT as an activity on node network. For this discussion, we will use the original form of activity on arc.

PERT planning involves the following steps:
1. Identify the specific activities and milestones : The activities are the tasks required to complete the project. The milestones are the events marking the beginning and end of one or more activities. It is helpful to list the tasks in a table that in later steps can be expanded to include information on sequence and duration.
2. Determine the proper sequence of the activities : This step may be combined with the activity identification step since the activity sequence is evident for some tasks. Other tasks may require more analysis to determine the exact order in which they must be performed.
3. Construct a network diagram : Using the activity sequence information, a network diagram can be drawn showing the sequence of the serial and parallel activities. For the original activity-on-arc model, the activities are depicted by arrowed lines and milestones are depicted by circles or "bubbles".
4. Estimate the time required for each activity : A distinguishing feature of PERT is its ability to deal with uncertainty in activity completion times. For each activity, the model usually includes three time estimates:
- Optimistic time : Generally the shortest time in which the activity can be completed. It is common practice to specify optimistic times to be three standard deviations from the mean so that there is approximately a 1% chance that the activity will be completed within the optimistic time.
- Most likely time : The completion time having the highest probability. Note that this time is different from the expected time.
- Pessimistic time : The longest time that an activity might require. Three standard deviations from the mean is commonly used for the pessimistic time.
Expected time for each activity can be approximated using the following weighted average:
Expected time = ( Optimistic + 4 x Most likely + Pessimistic ) / 6
To calculate the variance for each activity completion time, if three standard deviation times were selected for the optimistic and pessimistic times, then there are six standard deviations between them, so the variance is given by:
[(Pessimistic - Optimistic)/6]2
5. Determine the critical path : The critical path is determined by adding the times for the activities in each sequence and determining the longest path in the project. The critical path determines the total calendar time required for the project. If activities outside the critical path speed up or slow down (within limits), the total project time does not change. The amount of time that a non-critical path activity can be delayed without delaying the project is referred to as slack time.
If the critical path is not immediately obvious, it may be helpful to determine the following four quantities for each activity:
* ES - Earliest Start time
* EF - Earliest Finish time
* LS - Latest Start time
* LF - Latest Finish time
These times are calculated using the expected time for the relevant activities. The earliest start and finish times of each activity are determined by working forward through the network and determining the earliest time at which an activity can start and finish considering its predecessor activities. The latest start and finish times are the latest times that an activity can start and finish without delaying the project. LS and LF are found by working backward through the network. The difference in the latest and earliest finish of each activity is that activity's slack. The critical path then is the path through the network in which none of the activities have slack.
6. Update the PERT chart as the project progresses : Make adjustments in the PERT chart as the project progresses. As the project unfolds, the estimated times can be replaced with actual times. In cases where there are delays, additional resources may be needed to stay on schedule and the PERT chart may be modified to reflect the new situation.

PERT is useful because it provides the following information:
* Expected project completion time.
* Probability of completion before a specified date.
* The critical path activities that directly impact the completion time.
* The activities that have slack time and that can lend resources to critical path activities.
* Activity start and end dates.

The following are some of PERT's weaknesses:
* The activity time estimates are somewhat subjective and depend on judgment.
* Even if the activity times are well-estimated, PERT assumes a beta distribution for these time estimates, but the actual distribution may be different.
* Even if the beta distribution assumption holds, PERT assumes that the probability distribution of the project completion time is the same as the that of the critical path. Because other paths can become the critical path if their associated activities are delayed, PERT consistently underestimates the expected project completion time.

Defining a Task Set For The Software Project

No single task is appropriate for all projects. The set of tasks that would be appropriate for a large, complex system would likely be perceived as overkill for a small, relatively simple software product. Therefore, an effective software process should define a collection of task sets, each designed to meet the needs of different types of projects.

To develop a project schedule, a task set must be distributed on the project time line. The task set will vary depending upon the project type and the degree of rigor with which the software team decides to do its work. Most software organizations encounter the following projects :
- Concept Development projects : These projects are initiated to explore some new business concept or application of some new technology.
- New Application Development projects : These projects are undertaken as a consequence of a specific customer request.
- Application Enhancement projects : These projects occur when existing software undergoes major modifications to function, performance, or interfaces that are observable by the end user.
- Application Maintenance projects : The projects that correct, adapt, or extend existing software in ways that may not be immediately obvious to the end-user.
- Re engineering projects : These projects are undertaken with the intent of rebuilding an existing system in whole or in part.

DEFINING A TASK NETWORK
Individual tasks and subtasks have inter dependencies based on their sequence. A task network, also called an activity network, is a graphic representation of the task flow for a project. It is sometimes used as a mechanism through which task sequence and dependencies are input to an automated project scheduling tool. The concurrent nature of software engineering activities leads to a number of important scheduling requirements. Because parallel tasks occur asynchronously, the planner must determine intertask dependencies to ensure continuous progress toward completion. In addition, the project manager should be aware of those tasks that lie on the critical path.

Basic Principles of Project Scheduling

Scheduling is the culmination of a planning activity that is a primary component of software project management. When combined with estimation methods and risk analysis, scheduling establishes a road map for the project manager.

BASIC PRINCIPLES THAT GUIDE SOFTWARE PROJECT SCHEDULING
- Compartmentalization : The project must be compartmentalized into a number of manageable activities, actions and tasks. To accomplish compartmentalization, both the product and the process are decomposed.
- Interdependency : The interdependency of each compartmentalized activity, action, or task must be determined. Some tasks must occur in sequence while others can occur in parallel.
- Time allocation : Each task to be scheduled must be allocated some number of work units. In addition, each task must be assigned a start date and a completion date that are a function of the inter dependencies and whether work will be conducted on a full-time or part-time basis.
- Effort validation : As time allocation occurs, the project manager must ensure that no more than the allocated number of people have been scheduled at any given time.
- Defined responsibilities : Every task that is scheduled should be assigned to a specific team member.
- Defined outcomes : Every task that is scheduled should have a defined outcome. For software projects, the outcome is normally a work product or a part of work product.
- Defined milestones : Every task or group of tasks should be associated with a project milestone. A milestone is accomplished when one or more work products has been reviewed for quality.

Each of these principles is applied as the project schedule evolves.