The document provides guidance for students undertaking an individual software engineering project. It emphasizes that the focus is on demonstrating the software engineering process, not just producing working code. Students must submit documents showing their analysis, design, and development process. The project aims to give students experience working through the stages of a software project, from requirements to testing. Examiners are most interested in the coherence of the development process demonstrated through the documents.
IT 700 Final Project Guidelines and RubricOverviewAs the fin.docxADDY50
IT 700 Final Project Guidelines and Rubric
Overview
As the final stop in your journey toward your Master of Science in Information Technology, you will complete a capstone project that integrates the knowledge and skills you have developed in previous coursework and over the duration of the term by working to solve an information technology problem. To do this, you will develop a project proposal that identifies the problem you plan to solve. You will then design your solution and report on the implementation of your solution. You will also reflect on your project and your journey through the Information Technology (IT) program as well as how you plan to position yourself professionally.
Evaluation of Capstone
This capstone will be assessed somewhat differently than other courses you have taken online at SNHU. There are three separate components which will be submitted at different times during the course; however, they all operate together to comprise the whole capstone experience and
are not
assessed separately. You will be evaluated on all three as a unit in determining whether you have demonstrated proficiency in each outcome. Your work is expected to meet the highest professional standards.
This assessment will evaluate your mastery with respect to the following outcomes:
·
Develop innovative and agile, computer-based solutions to business problems through a systems analysis approach and technology integration and application
·
Design a plan for implementing and monitoring solutions that incorporate core information technologies, concepts, and methods appropriate for secure information use across an enterprise
·
Collaborate and communicate effectively in a variety of environments through situational awareness and audience analysis
·
Develop an implementation plan for systematic information risk assessment for change management plans and processes within enterprise business and information technology environments
·
Using computational logic and critical analysis, construct ethically sound, technology-informed procedures to ensure legal compliance and maintain security within enterprise information technology environments
Prompt
To simulate a real work environment, your capstone project will progress from developing a project proposal, to reporting on the design and creation of a project solution, to reflecting on the capstone experience. As you can see, writing is an important part of this capstone experience. IT professionals are not typically known for being great writers; however, successful IT professionals employ quality communication skills. The proposal, report, and reflection are opportunities for you to exhibit your superior written communication skills.
Working individually and with feedback from peers and your instructor, you will analyze a real-world problem that can be solved with information technology. The problem needs to have significance to your chosen discipline (database design, software progra ...
IT 700 Final Project Guidelines and RubricOverviewAs the fin.docxADDY50
IT 700 Final Project Guidelines and Rubric
Overview
As the final stop in your journey toward your Master of Science in Information Technology, you will complete a capstone project that integrates the knowledge and skills you have developed in previous coursework and over the duration of the term by working to solve an information technology problem. To do this, you will develop a project proposal that identifies the problem you plan to solve. You will then design your solution and report on the implementation of your solution. You will also reflect on your project and your journey through the Information Technology (IT) program as well as how you plan to position yourself professionally.
Evaluation of Capstone
This capstone will be assessed somewhat differently than other courses you have taken online at SNHU. There are three separate components which will be submitted at different times during the course; however, they all operate together to comprise the whole capstone experience and
are not
assessed separately. You will be evaluated on all three as a unit in determining whether you have demonstrated proficiency in each outcome. Your work is expected to meet the highest professional standards.
This assessment will evaluate your mastery with respect to the following outcomes:
·
Develop innovative and agile, computer-based solutions to business problems through a systems analysis approach and technology integration and application
·
Design a plan for implementing and monitoring solutions that incorporate core information technologies, concepts, and methods appropriate for secure information use across an enterprise
·
Collaborate and communicate effectively in a variety of environments through situational awareness and audience analysis
·
Develop an implementation plan for systematic information risk assessment for change management plans and processes within enterprise business and information technology environments
·
Using computational logic and critical analysis, construct ethically sound, technology-informed procedures to ensure legal compliance and maintain security within enterprise information technology environments
Prompt
To simulate a real work environment, your capstone project will progress from developing a project proposal, to reporting on the design and creation of a project solution, to reflecting on the capstone experience. As you can see, writing is an important part of this capstone experience. IT professionals are not typically known for being great writers; however, successful IT professionals employ quality communication skills. The proposal, report, and reflection are opportunities for you to exhibit your superior written communication skills.
Working individually and with feedback from peers and your instructor, you will analyze a real-world problem that can be solved with information technology. The problem needs to have significance to your chosen discipline (database design, software progra ...
CMGT 410 Week 1 Project Plan DraftA project plan is a docume.docxmary772
CMGT 410 Week 1 Project Plan Draft
A project plan is a document created at the beginning of the project lifecycle that gives stakeholders and everyone else involved in a project a clear idea of what a project will entail in terms of effort, time, cost, and anticipated results.
One of the things that must be identified before the project plan can be created is the methodology, or approach, the project manager plans to use to manage the project. Choosing a methodology is important because a methodology provides the framework—that is, an overall process and suggested documents and deliverables—that will guide project development from beginning to end. Some project methodologies are more appropriate for some types of projects than for others.
For this assignment, you will:
1. Choose a project methodology for two different projects based on project requirements, and explain why you chose each methodology for each project.
2. Brainstorm your own project and create a draft simplified project plan for that project. You must indicate in your simplified project plan whether you intend to apply the Agile or waterfall methodology. You may create your simplified project plan using Microsoft® Excel® or, if you choose, another software application such as Microsoft® Project®.
To complete this assignment:
Read Agile Project Management and the PMBOK® Guide.
Answer the Methodology Selection and Rationale questions.
Brainstorm a project you would like to explore in this course. You may choose a project from your work experience, from a description of a project in your textbook or in an online reading, or a project that is brand new but that you think would improve a business process at work, at home, or at school.
Read the two linked examples of project plans implemented as Microsoft® Excel® spreadsheets, Example Plan A and Example Plan B. You will be using these as guides in creating your own draft project plan. Notice especially the differences between these two examples in terms of length (overall and task length), structure of the work breakdown (iterative vs. non-iterative), and methodology.
Research additional project plan examples online.
Create a simplified project plan for your own brainstormed project that resembles the two linked examples.
Save your simplified project plan as a Microsoft® Excel® spreadsheet document.
Submit both your completed Methodology Selection and Rationale questions and your project plan draft (Microsoft® Excel® document).
CMGT 410 Week 2 Documenting the Project Lifecycle
Well-written project documentation clarifies intent, documents decisions and results, and allows project managers to assess project progress (and report it, as necessary, to project stakeholders) at every step of the project lifecycle.
For this assignment, you will create two examples of project documentation that align with the Project Plan Draft assignment you completed in Week 1. The documentation you will create for this assignment aligns with the initi.
Introduction to Software Engineering, Software Process, Perspective and Specialized Process Models – Introduction to Agility – Agile process – Extreme programming – XP process - Estimation-FP,LOC and COCOMO I and II,Risk Management, Project Scheduling.
These slides were used to teach the module "Introduction to Agile Software Development & Python" as a sub-section of the major course "Software Engineering" for the 3rd year undergraduates of the Department of Computer Engineering, University of Peradeniya in 2010.
Software Engineering in a Quick and Easy way - v1.pdfKAJAL MANDAL
The Most Common must know Software Development life cycle Models. As we discussed in our earlier article on Software Engineering, we have learned about the aspects of Software Engineering and the qualities that it should possess. Now let us move ahead and learn about the models of the software development life cycle. What is a software development life cycle? A software development life cycle, sometimes also called the SDLC life cycle, represents and describes the various activities that are to be performed to build a software product. These activities are grouped into several phases and sequentially linked in order. Hence we can also say, that a software development life cycle is a structured list of activities that are followed to develop software, from the inception to the delivery of the final product. During any phase of the life cycle of development, one or more activities might have to be carried out to start or finish that phase. For example, in the inception phase of actual coding, it is expected that the architectural designing phase is completed. Why software development life cycle model is required? In every model of SDLC, every phase may have its own child life cycle, for every team of a specific skill set. So in an environment of complicated projects and a variety of skill-based teams, it is vital to follow a pre-defined structured process. This creates discipline and maintains decorum in the working culture. All team members are interdependent. Failure of any one team will affect the deliverables of other teams. And all together it might lead to project failures. SDLC also defines entry and exit criteria for every phase. For example, say, if a team member starts coding, assuming that pro-activeness will help finish the project much earlier. This would be the perfect recipe for disaster and project failure. Why? Because, after putting down a month of effort they might realize that the project needs a roving vehicle on Mars to collect data. Unfortunately, the team doesn’t have that with them. So they can not proceed further. That means a feasibility study was not performed before the team started working on deliverables. Which in technical terms, is a breach of SDLC, and hence the loss of effort, or project failure. The team should have done a feasibility study before jumping straight into deliverables. Then they would have realized that the project is not doable, many days in advance. As so, they could have saved some unnecessary effort. Hence it is strongly suggested to follow a methodology, or process while working on complex and team-based projects. It becomes easier for the entire team to work together, support each other, manage, and track the progress of the development. Regardless of the model you follow, SDLC models always ensure smooth delivery, reporting, and chaos-free delivery of the project. Classic Waterfall Model. Prototyping Model. Iterative Waterfall Model. Rapid Action Development. Spiral Model.
CMGT 410 Week 1 Project Plan DraftA project plan is a docume.docxmary772
CMGT 410 Week 1 Project Plan Draft
A project plan is a document created at the beginning of the project lifecycle that gives stakeholders and everyone else involved in a project a clear idea of what a project will entail in terms of effort, time, cost, and anticipated results.
One of the things that must be identified before the project plan can be created is the methodology, or approach, the project manager plans to use to manage the project. Choosing a methodology is important because a methodology provides the framework—that is, an overall process and suggested documents and deliverables—that will guide project development from beginning to end. Some project methodologies are more appropriate for some types of projects than for others.
For this assignment, you will:
1. Choose a project methodology for two different projects based on project requirements, and explain why you chose each methodology for each project.
2. Brainstorm your own project and create a draft simplified project plan for that project. You must indicate in your simplified project plan whether you intend to apply the Agile or waterfall methodology. You may create your simplified project plan using Microsoft® Excel® or, if you choose, another software application such as Microsoft® Project®.
To complete this assignment:
Read Agile Project Management and the PMBOK® Guide.
Answer the Methodology Selection and Rationale questions.
Brainstorm a project you would like to explore in this course. You may choose a project from your work experience, from a description of a project in your textbook or in an online reading, or a project that is brand new but that you think would improve a business process at work, at home, or at school.
Read the two linked examples of project plans implemented as Microsoft® Excel® spreadsheets, Example Plan A and Example Plan B. You will be using these as guides in creating your own draft project plan. Notice especially the differences between these two examples in terms of length (overall and task length), structure of the work breakdown (iterative vs. non-iterative), and methodology.
Research additional project plan examples online.
Create a simplified project plan for your own brainstormed project that resembles the two linked examples.
Save your simplified project plan as a Microsoft® Excel® spreadsheet document.
Submit both your completed Methodology Selection and Rationale questions and your project plan draft (Microsoft® Excel® document).
CMGT 410 Week 2 Documenting the Project Lifecycle
Well-written project documentation clarifies intent, documents decisions and results, and allows project managers to assess project progress (and report it, as necessary, to project stakeholders) at every step of the project lifecycle.
For this assignment, you will create two examples of project documentation that align with the Project Plan Draft assignment you completed in Week 1. The documentation you will create for this assignment aligns with the initi.
Introduction to Software Engineering, Software Process, Perspective and Specialized Process Models – Introduction to Agility – Agile process – Extreme programming – XP process - Estimation-FP,LOC and COCOMO I and II,Risk Management, Project Scheduling.
These slides were used to teach the module "Introduction to Agile Software Development & Python" as a sub-section of the major course "Software Engineering" for the 3rd year undergraduates of the Department of Computer Engineering, University of Peradeniya in 2010.
Software Engineering in a Quick and Easy way - v1.pdfKAJAL MANDAL
The Most Common must know Software Development life cycle Models. As we discussed in our earlier article on Software Engineering, we have learned about the aspects of Software Engineering and the qualities that it should possess. Now let us move ahead and learn about the models of the software development life cycle. What is a software development life cycle? A software development life cycle, sometimes also called the SDLC life cycle, represents and describes the various activities that are to be performed to build a software product. These activities are grouped into several phases and sequentially linked in order. Hence we can also say, that a software development life cycle is a structured list of activities that are followed to develop software, from the inception to the delivery of the final product. During any phase of the life cycle of development, one or more activities might have to be carried out to start or finish that phase. For example, in the inception phase of actual coding, it is expected that the architectural designing phase is completed. Why software development life cycle model is required? In every model of SDLC, every phase may have its own child life cycle, for every team of a specific skill set. So in an environment of complicated projects and a variety of skill-based teams, it is vital to follow a pre-defined structured process. This creates discipline and maintains decorum in the working culture. All team members are interdependent. Failure of any one team will affect the deliverables of other teams. And all together it might lead to project failures. SDLC also defines entry and exit criteria for every phase. For example, say, if a team member starts coding, assuming that pro-activeness will help finish the project much earlier. This would be the perfect recipe for disaster and project failure. Why? Because, after putting down a month of effort they might realize that the project needs a roving vehicle on Mars to collect data. Unfortunately, the team doesn’t have that with them. So they can not proceed further. That means a feasibility study was not performed before the team started working on deliverables. Which in technical terms, is a breach of SDLC, and hence the loss of effort, or project failure. The team should have done a feasibility study before jumping straight into deliverables. Then they would have realized that the project is not doable, many days in advance. As so, they could have saved some unnecessary effort. Hence it is strongly suggested to follow a methodology, or process while working on complex and team-based projects. It becomes easier for the entire team to work together, support each other, manage, and track the progress of the development. Regardless of the model you follow, SDLC models always ensure smooth delivery, reporting, and chaos-free delivery of the project. Classic Waterfall Model. Prototyping Model. Iterative Waterfall Model. Rapid Action Development. Spiral Model.
Maruthi Prithivirajan, Head of ASEAN & IN Solution Architecture, Neo4j
Get an inside look at the latest Neo4j innovations that enable relationship-driven intelligence at scale. Learn more about the newest cloud integrations and product enhancements that make Neo4j an essential choice for developers building apps with interconnected data and generative AI.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
How to Get CNIC Information System with Paksim Ga.pptxdanishmna97
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
Unlocking Productivity: Leveraging the Potential of Copilot in Microsoft 365, a presentation by Christoforos Vlachos, Senior Solutions Manager – Modern Workplace, Uni Systems
1. Chapter 16: The project
Chapter 16: The project
Introduction
For this unit you are expected to undertake an individual software-
engineering project and to submit a project report to London. You should
take some care in selecting a project topic and preparing for this substantial
task. To achieve good results in this unit you will need to devote substantial
time to this project and ensure that you work on your project consistently
over the year. In past years some students have failed their project because
they started work on it too late or failed to keep work up throughout the
year. There is no way that you can ‘rush’ the project at the last
moment.
You should also understand that the idea of the project is to demonstrate
an understanding of the software engineering process and professional
practices. It is not intended to be about producing computer programs for
their own sake. In fact, you are not required to deliver a fully
running computer program with your project. The crucial part of
your project is the description of the development process which is a
model-based task. You are merely required to implement parts of your
system in order to demonstrate that the design you have created can
actually be translated into program code, and to undertake some testing of
the crucial parts.
The time you devote to your project will be of benefit to you when it comes
to sitting the examination. The experience of developing your own project
will show through in the examination, and will provide you with important
examples of how systems development works in practice. You will know
what you are talking about. Indeed the problems, frustrations, moments of
breakthrough, difficulties and joy you will feel undertaking this work are
the same as those experienced by software engineers in their daily work.
In a section below, I provide some ideas of possible projects that you might
like to consider. You are, however, encouraged to develop your own project
idea for small and medium scale software systems. In general, you should
understand that we are looking for a system that allows you to carry out a
software engineering process which leads to a model of a complete system.
At the end of the project these models should be capable of being easily
developed as software code. This should also include some small coded
elements of the significant parts of the project – for example to
demonstrate and test how a crucial algorithm is performed.
Students coming to this unit are expected to have some experience of
various package environments including databases and spreadsheets. You
are also expected to have a general understanding of programming and
some programming skills (through the units Elements of information
and communication technologies and/or Introduction to
Programming). While you will probably undertake some programming,
and so develop these skills, you should understand that the main emphasis
of this unit is not to teach you more programming, but rather to
concentrate on the intellectual work that leads up to and surrounds the
coding activity.
Details on how to submit the project and the date by which the entire
project must be in London are given in the booklet Completing and
submitting coursework and projects which all students taking this unit
113
2. Software engineering: theory and application
should receive. This booklet is revised each year, and you should make sure
that you have the most recent edition. The booklet contains the exact
deadlines for each year, the forms required to accompany your project and
details of how to submit the project.
Overview
The project, which counts for 40 per cent of the final mark, is intended to:
• take you through the process of developing a sophisticated piece of
software, tackling a realistic problem
• provide practical demonstrations of the key issues discussed in the
subject guide. It is when doing the project that you will come to
realise the importance of good requirements analysis and design, the
benefits of setting up a proper testing process and the problems of
keeping to deadlines and managing projects
• be an enjoyable experience where you can make the mistakes that you
will learn from.
In order to complete the project you are required to produce a number of
documents. It is very important that you maintain coherence
between the documents you create.
In addition to these documents, you are expected to write a final project
report. The main section of the final project report provides a summary of
the lessons you learned, what went well and what you would do differently
next time.
You should note that the focus of the project is not on the system produced,
but on the quality of the process undertaken, the coherence of the
documents presented, and how successful the documents would be in
developing a software system.
One way to think of the project is as an attempt to produce a set of
documents which could be sent to an outsourcing company to ask them to
produce a system for you. Your aim is to produce a set of documents which
would enable the outsourcer to understand what was needed, and go
ahead and produce the complete software system.
The project as a development process
The aim of the project is to give you the experience of the processes and
practices of software engineering. As such, we intend you to undertake the
process of analysing and designing a software product, and submit to us
the documents you used in this process. This means that the documents
should be the practical documents you would use to develop the system.
Before you hand in your project, you could of course go back over your
individual documents again and edit them. However, although you could
go back and change, for example, an initial system requirement so that
they match exactly (and surprisingly) your final design, this is not what the
examiners are looking for. We are much more interested in how you
progressed through the various stages of your project than in the final
result.
In the past many students have achieved a poor mark in their project,
because they have paid too much attention to one part of the process
(usually coding the software) and far too little attention to the coherence of
their development process overall. A project that has many problems
throughout its development process may be rated as highly as one where
everything went well. What is important is that the project documents
114
3. Chapter 16: The project
demonstrate how problems faced were addressed. Examiners are much
more interested in seeing a genuine learning effort that uses the methods
and techniques of software engineering than a running system. Remember
that even professionally produced software regularly fails – we are looking
for the professional approach to software design.
Examiners would be happy to see a page in the later stages of design which said
something like ‘The initial user requirement for XYZ was unachievable as it conflicted
with the other requirement for ABC. It is therefore decided that XYZ is to be dropped
from the design.’ This is the kind of thing seen in real software engineering projects all
the time, so why should your project be any different?
When you write and edit your project, remember Brook’s comment (1995):
‘Most documentation fails in giving too little overview; the trees are
described, the bark and leaves are commented, but there is no map of the
forest. To write a useful prose description, stand way back and come in
slowly’.
It is essential that your documents form a coherent project in which the
examiners can see how the individual development stages have been
carried out and how they relate to the previous and the following stages.
Finally, remember we are very unlikely to reward the ‘software hacker’ who
works through the night to come up with a wonderful piece of software
without bothering to undertake requirements analysis or design properly,
by faking the testing, and by ignoring proper planning. Yes, this person
might produce something which looks impressive, but do not expect marks
for producing a system in a way that does not take into account
requirements, and which is likely to be unreliable and dangerous.
Choosing your development tool
You are encouraged to make use of development tools in your project;
however, this is not a formal requirement so do not feel you have to. You
may want to use modelling tools, design tools etc. In addition you will need
to produce small amounts of software to demonstrate how aspects of the
design will operate. For this you may either want to choose a programming
language, like for example Pascal, Visual Basic, C++ or Delphi.
Alternatively, you may want to choose a spreadsheet or database package.
Although programming languages offer the greatest flexibility, some
application areas may be best suited to, for example, a database package.
Your choice should depend on the kind of application you are designing
and the development tool you have access to. If you choose the object-
oriented development approach for your project you will probably want to
use an object-oriented language to undertake any coding.
Although the project does not require you to write the program
code for a fully running system, you will have to do some
programming of some of the important parts. It is essential that you start to
acquire the necessary programming skills as soon as possible. The unit
Elements of information and communication technologies and
possibly Introduction to programming has given you an introduction
to the component parts of a program. You should be able to use these
concepts within the programming language you have chosen.
You are not expected to write the code for a fully running and
complete system. You must, however, deliver sufficient coding to
demonstrate how a small number of complex elements of your design can
be translated into code. As such you are only expected to produce
programming stubs rather than a complete system.
115
4. Software engineering: theory and application
A programming stub is a small section of code which a developer uses to
demonstrate a principle or idea, and to test that it works. A programming
stub might implement a single Class, or even just one of a class’s methods,
if that method undertakes complex processing (for example an Order class
might have a method GetPrice() which calculates the prices by processing a
range of inputs. You could produce a programme stub to test that you
understand how this would work, and that your design is correct).
This is not the same as pseudocode as a programming stub must be written
in a programming language so that it can be tested. They are usually pretty
short (at most a couple of pages in length) and implement the most
difficult parts of the system (so the developer can test and verify the
important parts of the system before we waste time on the easy parts). It is
also usual to develop some kind of interface to interact with the
programming stub (for example a way of reading a file of attributes, of
calling the program stub with these attributes, and of displaying or saving
the returned parameters).
Examples of other things you might implement are:
• some user interface screens, since these may be needed to produce
your user manual
• if you use a database you will need to provide most of the database
schema
• if you are using data files you will need to describe their format.
Additionally, you should remember that it is very important that you
explain any programming stubs etc. you provide. They should be written
with sensible variable names, and plenty of comments in the code. You
should describe how they would be used within the complete system, and
how they relate to the design activity. Finally, you should provide details of
what components require further implementation.
You are required to provide a printed copy of the source code you produce
as an appendix to your project. In addition, you should submit a disk
containing executable versions of the parts of the system which have been
coded. These do not necessarily need a user interface (you could just ask
for input from the command line, or by reading a file), but must be
relatively easy for the examiner to try.
Those students who are very keen to implement a complete system rather
than just programming stubs can do so. Such students should however
remember that only a small proportion of the marks is allocated for the
programming component of the project, and therefore it is not likely to
drastically improve their marks and could damage their marks by diverting
their attention from the important tasks.
Reuse
Reuse is an important part of software development, and you are
encouraged to reuse code or models and patterns, and auto-generated
code, to aid you in your development of the programming stubs. However,
to avoid charges of plagiarism you must make it clear which
elements of your project constitute reuse. All that we ask is that
you indicate to us the pieces of code that you did not write (or alternatively
highlight the pieces you did) and tell us where the code you are reusing
came from (by referencing its source). You should do this on the source-
code that you submit as part of your report; for example, why not put all
your own code in bold or italic, or you could put comments into the code
where the auto-generated or reused part starts and ends. This allows you to
116
5. Chapter 16: The project
download small sections of code from the Internet and use them as long as
you highlight to us that you are reusing the code. If you fail to do this
you could be accused of plagiarism (cheating), rather than
being rewarded for taking advantage of reuse.
Suggested projects
You are expected to choose your own project to work on. A suitable project
will probably have most of the following characteristics: It will:
• handle some real world data of non-trivial complexity
• require a user-interface tailored to some defined user (who should not
be you)
• undertake some processing/calculation/selection on the data it
contains.
Conceptually a project does not have to be very big to present a real
challenge – as the examples below show, a database type application
tailored to some particular domain is a good starting point.
Projects that do not contain a substantial software analysis and design
component are not suitable. For example developing a computer game is
not appropriate as it does not have specific user requirements (other than
perhaps being enjoyable for users!).
When choosing a topic, remember that you need a project that will enable
you to demonstrate your understanding of the whole software engineering
process. Below is a list of projects you may choose from if you wish:
A personal data management system
This would consist of a small database management system used to record
personal information such as details of records and books, information
about recipes and so on. There may be a diversity of information recorded,
and the system should be easily used by people without a computer
background.
A photograph library sales system
This records and retrieves information about photographs in a library and
the worldwide sales of these photographs. It should support keyword
classification and retrieval requests for different types of photographs. It
should maintain details of fees received and due for each photograph that
is published. Again, the system should be designed for use by people who
are not familiar with computing aspects.
An online recipe and meal planner
This could compute the overall nutritional value of a meal, summarise the
necessary ingredients, and estimate costs. It might also be able to suggest a
meal given ‘I want to use up this corned beef’ or ‘I’m out of eggs and
lettuce’.
A personal organiser for a university lecturer
This would schedule the lecturer’s teaching, send reminders when
necessary (possibly through an e-mail system), perhaps co-ordinate with
other lecturers’ (or even students’) calendars for scheduling meetings, and
so on. Printing parts of the calendar on demand is a must. Questions that
such an organiser should be able to answer include ‘What’s up for today?’
117
6. Software engineering: theory and application
or ‘Let’s see next week at a glance’ or ‘What in the world was I doing last
Tuesday?’ or ‘On what day of the week for the next four weeks is there an
hour free starting at 10:00?’.
A terminal reservation system for a computer terminal room
This would be an automated sign-up sheet for a collection of terminals
(and possibly other resources). People should be able to express
preferences for various times. The system should include facilities for
administrators to collect and print statistics on usage as well as a
scheduling algorithm to ensure fair distribution of resources among users.
It should be easy to change the scheduling algorithm. (Ignore the fact that
you need to use a terminal to sign up for a terminal. For example, assume
that one is reserved for this purpose.)
An online holiday planning system for a busy department
This allows staff to choose and book when they are on holiday. It might
also need details such as who is taking over the person on holiday’s work,
where they can be contacted etc, and maybe make sure that important
people are not off at the same time.
An online system for managing bookings
This might be for a cruise liner or railway.
Deliverables
The deliverables are split into three sections. The first section involves
planning how you will approach the software engineering project. The
second section contains all the documents you produce in undertaking the
project (the models etc). The third section asks you to assess your project
critically, and reflect on the learning it has given you.
Deliverables section 1: project description and planning
This section is an important task as you need to ensure that you can
complete all the necessary documents on time. You should not take it
lightly, and should use project management techniques to help you plan.
You should ensure that you produce a timetable for undertaking the
project, including plenty of contingency time should things go wrong and
including time off, holidays etc. It is important that you balance the
demands of this project with the need to study the subject and
relax. Remember that the project accounts for 40 per cent of
your mark, and should therefore constitute no more than 40
per cent of the time you put to study software engineering. The
project can expand to fill the time available, so make sure you
limit this by planning your activity well and sticking to your
timetable. Indeed, it is better to decide to cut your project
down (for example by ignoring certain requirements) so that
you can finish it than to hand in a half-completed project. If
you need to do this you must explain why you took this
decision in your document.
It is essential that you stick to your timetable in order to avoid severe time
pressure towards the end of the project and to get maximum benefit from
the project. Remember that you will be marked on the entire development
process and not only on the end product. If you start your project too late
118
7. Chapter 16: The project
you will not have enough time to carry out all the stages that are part of
software development.
In no less than two pages you should summarise the project you propose to
work on:
• Give your system a name.
• Describe what the system will do and who its users will be. What
needs will your system satisfy? How will it help the users?
• Outline the most important features of your system.
• Describe the physical environment in which your system will be used
including any other systems with which the new system will interface.
• Are there any important performance goals for your system: time or
space efficiency, security or reliability?
On another two to three pages you should describe the software
engineering process you intend to employ, and how this is relevant to the
system you describe:
• Outline the basic principle of the chosen approach (including
references to relevant literature on this approach). You should also
establish the software development paradigm you have chosen (i.e.
structured or object-oriented).
• Discuss why this process is suited to the problem previously described.
• Provide a very detailed timetable for the activity you are going to
undertake and a detailed plan of the documents you will be providing
and how they will address the need for requirements analysis, design
and elaboration, approaches to implementation, documentation of the
system, and testing. You can use diagrams such as Gannt charts for
this if you wish.
• Consider any problems you might envisage encountering and how you
intend to manage such risk.
You can also use this section to plan how you will manage the
development project and keep to your timetable.
Deliverables section 2: the software engineering practice documents
In the next section of your project you must provide documents which
outline how the software engineering process was undertaken in terms of
analysing the user’s requirements, undertaking design, elaborating that
design, approaching implementation, documenting the system and
undertaking testing. The format for this section depends on the software
engineering processes you have decided to follow (as detailed in section
1).
Examples of the documents you might produce for different software
engineering processes:
Pressman chapter 2 provides a good description of various software
development processes and the types of documents which might be
produced. Below we provide examples of the different sections which
might be produced for projects following different development
processes.
119
8. Software engineering: theory and application
For a project following the software development lifecycle the contents of
the section may look like this:
1. Requirements analysis.
(a) Introduction.
(b) Functional requirements and conceptual model.
(c) Non-functional requirements.
(d) Hardware.
2. Detailed requirements analysis.
3. Design.
4. User manual and maintenance manual.
5. Coding of key algorithms and database schema.
6. Testing document.
In contrast, a student trying to follow the Rapid Application Development
approach (clearly without the team working elements) might have a
document of this form (or similar):
1. Cycle 1
(a) Business modelling.
(b) Data modelling.
(c) Process modelling.
(d) Stub application generation using Visual Basic.
(e) Testing and turnover.
2. Cycle 2
(a) Further business modelling using feedback.
(b) Further data modelling.
(c) Further process modelling.
(d) Application elaboration and changes.
(e) Testing and turnover.
3. Cycle 3
4. User manual of the final system.
Finally, a project which is following the spiral model might have the
following sections (or similar):
1. Spiral 1
(a) Customer communication.
(b) Planning documents – construction of task sets.
(c) Risk analysis.
(d) Engineering (including analysis and design) of tasks.
(e) Construction and release of algorithms central to the problem and
considered of high risk. Construction and release of prototype user
interface.
(f) Requirements planning.
2. Spiral 2
(a) Risk analysis.
(b) Prototype 2 construction (including simulations of a small user
interface).
(c) Detailed requirements and requirements validation.
(d) Development planning.
120
9. Chapter 16: The project
3. Spiral 3
(a) Risk analysis.
(b) Prototype 3 construction (including simulation and benchmarking of
core algorithms).
(c) Design of the complete software product.
(d) Validation of the design.
(e) Test planning.
4. Spiral 4
(a) Risk analysis.
(b) Further design activity to elaborate section 3(c).
(c) Implementation of core algorithm code.
(d) Unit testing.
(e) Acceptance testing.
5. User documentation of system.
Note that just because some of these projects have many more sections, it
does not mean that they should be longer in length, nor involve more
work. You should also try to avoid unnecessary repetition in your
documents. For example you do not need to include every test case you
undertook.
Note that each of these examples differs in some way from the way
textbooks describe the processes. This is expected as it is unlikely that a
project that is undertaken by one developer who has little experience will
precisely follow a formal software development project. You should decide
which sections you need.
Whatever form your documents take, they must include descriptions of
how you undertook the following activities:
You must document how you captured requirements and turned these
into design
This should include some description of the need for the system and place
the system into context, briefly describing its functions and presenting a
rationale for the software system.
Functional requirements – the conceptual model
Your documents should describe the functions that the system will perform
(i.e. it should present the conceptual model of the requirements of your
system). This means that you will have to model your functional
requirements applying (for example) levelled data flow diagrams, entity-
relationship diagrams if you are following the structured approach, and you
will have to produce use-case diagrams and class diagrams if you opt for
object orientation.
It is very important that you document your modelling processes very
carefully. You are expected to explain how they support the further analysis
of your particular problem domain. However, keep in mind that you are not
supposed to give an explanation of how exactly certain modelling
techniques such as, for example, data flow diagrams work.
Non-functional requirements
You should state all non-functional requirements, such as technical
constraints or security requirements, your system might have.
121
10. Software engineering: theory and application
Hardware
If the system is to be implemented on special hardware, this hardware and
its interfaces should be described. If off-the-shelf hardware is to be used,
the minimal and optimal configuration on which the system may execute
should be set out here.
You must document how you approach the design of the system
You must outline the top level decisions you have made, and how these
decisions were broken down into components, how these components are
linked, etc.
The overall design within structural software development, for example, is
concerned with determining the modules and how the modules are linked
and interact with each other. For this purpose you would have to apply
structured design and create structure charts from your data flow diagrams.
The overall design within an object-oriented approach requires you to
model interaction and object behaviour using sequence diagrams and
statecharts.
After this you will need to describe how you elaborated these designs,
adding sufficient detail to them so that it can be used as a reference from
which any competent software engineer can produce code, set up the
testing process, and write a user manual and a system maintenance guide.
The detailed design should include answers to all of the questions for as
many levels as possible.
The detailed design within structured development, for example, will have
to provide the details of the algorithms used within the individual modules.
The detailed design within an object-oriented approach involves the exact
definition of classes (with their attributes and operations) and the messages
sent between objects. You may want to use pseudocode (an outline of
programming code) in order to represent the details required within
detailed design.
During the design process you should focus on the parts of the design that
are essential to producing a core system. You only need to outline the
extensions to a more complete system. Also, do not waste time and energy
repeating the details for parts that have a similar structure. Instead you
should give one design example and explain which parts (and why) follow
the same or a similar design pattern. One of your major goals is to develop
a model that is complete by the deadline. This is not expected to be the full
system. It is essential that you review the entire design process to ensure
that everything has been covered, that the parts of the documents hang
together, and that the design can be related to the requirements.
The user manual
This document should be a self-contained description of how to use your
system. A user manual should be a polished, professional piece of technical
prose that a software company is proud to have accompanying one of their
products. (Also, it is a handy accomplishment to show off at job
interviews.)
The document should have a structure that is evident both to someone
reading it straight through and to someone looking for a particular topic or
fact. A table of contents is required, and the organisation it reflects should
be considered carefully. An index and appendices might also be helpful.
122
11. Chapter 16: The project
Remember, the document should be completely self-explanatory. Do not
assume the reader has seen your functional specification. You may, of
course, edit in sections of prose from your previous documents. Do not
discuss any implementation unless it directly affects the user’s interface to
the system.
Your document ought to cover the list of topics below. The exact order in
which you present material and whether certain topics are combined
should be dictated by your particular project and your own style of writing.
• Introduction: a concise statement of what your program does, possibly
including motivation and philosophy.
• How to use your system: an overall description of the style of user
interaction, device constraints, and any arbitrary design choices you
made that the user ought to know about.
• Detailed system operations: an organised list of all the user commands
and when they are appropriate. Some examples (preferably with
screenshots) might be helpful. Also, it is often appropriate to divide
the user manual into a novice section and an expert section.
• Error recognition and handling: what are the errors that might occur,
and how can they be handled?
• An extended example: show exactly what the user may have to type or
what buttons he might have to press (and why) and how the system
responds (and why).
• A list of known ‘features’ and deficiencies: everyone complains about
how cryptic current computer manuals are. This is your chance to
show us what a good manual looks like.
Outline of the programming stubs/examples you have produced as part
of your design activity
You do not need to implement the complete software; however, you do
need to produce some of the key algorithms – for example, you may need
to implement a couple of classes or models to demonstrate how they would
be achieved. These should be included in your documents along with a
description of what they are for and how they work. You should also
highlight any code-reuse, and ensure that the code is commented and
consistent with the design and requirements.
A description of the testing you undertook as part of the software
engineering process
Testing is an important part of a software project. Testing needs to
accommodate both system verification and validation. The software team
must carefully plan the different testing stages, develop a schedule of when
they are to be carried out, design the test cases that are needed and
eventually collect and evaluate the test results. Accordingly, the software
team must document the order in which modules or classes are to be
integrated and the order in which the individual modules or classes are to
be tested in isolation. Testing and debugging methods must also be agreed
upon, documented, and eventually carried out.
The purpose of a testing document is to convince the management (in this
case, the examiners) that a feasible testing approach has been designed and
undertaken. You are expected to schedule several stages of your tests.
Scheduling is required for unit testing, integration testing, and validation
123
12. Software engineering: theory and application
testing. You should note that the schedule of testing, and the tests
undertaken, will vary depending on the software development process you
have chosen.
In documenting your testing you should include an introductory section
that summarises how testing was undertaken. This should include a
description of how testing was planned and undertaken in detail.
Remember that this description is intended for several audiences. The
document should be organised so that it is easy to find schedule summaries
and monitoring plans.
Your description of the testing should contain the following components:
• a statement of the objectives and success criteria
• an integration plan
• a plan of the testing techniques and test cases used
• a testing schedule
• a summary of the test results and debugging procedures applied.
These components are described in more detail below.
Objectives and success criteria
The testing document should contain a statement of the overall testing
objectives and the objectives of the individual tests that are planned.
Integration plan
It is important to decide the order in which modules or classes are to be
combined and therefore the order in which they will be tested individually.
You must plan for individual module tests, the combination of modules
during integration testing, and a validation test that tests the functionality
of your system.
The testing document should describe and justify your integration method.
The ‘big bang’ method of integration is not acceptable, but many variants
or combinations of top down and bottom up integration (or an appropriate
alternative within an object-oriented approach) are acceptable if
convincingly defended.
Testing techniques and test cases
You should design a plan to test all of the modules (or classes) of your
system. Your testing document should state what kind of testing technique
is applied to test the components of your system, and it should explain why
a particular technique has been chosen. It is very important that you
establish the test cases you will use. Keep in mind that a test case includes
the test input and the expected output against which the actual test output
will be compared. You do not need to carry out your tests for all
components. However, you will want to employ some basic testing
techniques to test the main algorithms within your system (those
implemented as programming stubs). The purpose of this is that you
demonstrate that you are able to select and employ some relevant testing
techniques.
Schedule
The testing document should provide a schedule describing the dates of the
different tests to be carried out within your chosen software engineering
process. First, determine an order in which to perform integration and
validation (functional) tests. This order should be used to determine the
124
13. Chapter 16: The project
order in which the individual modules (components) are to be tested.
Determine the dates by which tests are to be completed. Finally, you must
define a monitoring procedure to ensure that tests are designed and carried
out on schedule. There must also be a procedure for reporting and
correcting bugs. Note that if you are following a evolutionary approach
your schedule may include many cycles of activity.
Test results and debugging procedures
Finally, you should interpret the outcome of your tests and report on the
errors that have been found and the action taken to locate and correct
them.
Deliverables section 3: the final project report
The purpose of the final report is to give an overview and evaluation of
your entire project. This is an important document for the markers as it is
used to evaluate what you have learnt from your project and from the
process you have chosen. The document should be around two pages long.
The document provides an opportunity to step back and put things in
perspective and appreciate how much you have accomplished. In your
report you should cover the following issues.
• What changed: You should discuss how well your project satisfied
the users. Did it do what they wanted? What did you leave out and
why?
• The software process: Were you satisfied with the chosen
approach? What problems did you encounter? Where did you break
from the usual approach to the process?
• Developing the system: Do you think your document could really
be used to develop a software system? What is missing? What is going
to be difficult for someone to follow? Note you will not lose marks for
highlighting problems with your system.
• Management: Compare the actual time spent on the project with
your predicted times. Have your learned anything that will help you
make better predictions next time?
• Lessons learnt: Here you should list the things you have learnt
from doing the project.
• Final comments: If there is anything that you really want to get off
your chest about the way you did the project that would be valuable
for other students, you should put them into this section.
Finally, on a separate set of pages you should include the following:
• Bibliography: You should list the books and papers which you used
to help you develop your system. These should not be the standard
textbooks and can include manuals, web sites and journal articles.
• Software used: List the software you used in developing your
system.
125
14. Software engineering: theory and application
Marking the project:
In marking the project the examiners will be looking explicitly for the
following main elements:
1. The completeness and correctness of the report (around 50 per cent of
the marks). In particular, they will ensure that you have chosen a
relevant process, that you have followed your outlined process well
with requirements being captured, design undertaken, the design
elaborated, a user manual being written, a small amount of relevant
programming stubs being produced which reflect the design, and that
relevant and appropriate testing was undertaken. A project which is
problematic can gain some marks for correctness by reflecting on the
problems in the final report.
2. The coherence and structure of the report (around 30 per cent of the
marks). Examiners will give marks on how coherent the development
paradigm and process are, how well they are followed, and that the
project holds together as a complete system. For example, marks will
be lost if the data structures in the coding stubs are not related to the
initial designs, ER diagrams or Class diagrams.
3. Sophistication (around 20 per cent). Examiners will award some
marks for how sophisticated the project is – this is not simply in terms
of how complex the problem addressed is, but also how sophisticated
the process is, how well the techniques are applied and how well the
document is written and presented.
126